Az e-közigazgatás releváns ismereteinek, nemzetközi gyakorlatának és megoldásainak győjtése ÍRORSZÁG

Az e-közigazgatás releváns ismereteinek, nemzetközi gyakorlatának és megoldásainak győjtése ÍRORSZÁG

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:

Metaadat-táblázat Megnevezés Cím (Title) Kulcsszó (Subject) Leírás (Description)

Dokumentum Az e-közigazgatás releváns ismereteinek, nemzetközi gyakorlatának és megoldásainak győjtése: ÍRORSZÁG Best practice folyamatok ismertetése Jelen tanulmány célja, hogy áttekintést adjon az ír ekormányzati keretrendszer kialakatásának legjelentısebb lépéseirıl, ill. a rendszer legfontosabb elemeirıl. A második fejezetben rövid történeti leírást ad az ír eközigazgatás legfontosabb mérföldköveirıl, az 1999-ben meghírdetett állami Akciótervtıl a 2002-ben megfogalmazott „Új kapcsolatok – Stratégia az információs társadalom potenciáljának realizálására” jelentésig, és ismerteti az ír e-közigazgatás legfontosabb szereplıit, feladataik rövid bemutatásával. Ezt követıen részletesebben is bemutatja az ír e-közigazgatás infrastruktúráját, így a kormányzati www.basis.ie, portálokat (www.citizeninformation.ie, www.reachservices.ie), a Reach Ügynökséget, a Közigazgatási Szolgáltatás Brókert (PSB), az e-kormányzati gerinchálózatot, a hatósági ügyintézést és az e-közbeszerzést segítı rendszereket. A harmadik fejezet bemutatja, hogy milyen keretrendszerek kerültek kialakításra eddig Írországban és ismerteti az ír e-kormányzati interoperabilitási keretrendszert. Kitér a Reach projekt legmeghatározóbb szakaszaira és a Közigazgatsái Szolgáltatás Bróker (Public Service Broker - PSB), mint az intézményközi adatkapcsolat alapját adó rendszer felépítésére. Az ír e-kormányzat egyik nagyszabású projektje volt a Public Service Broker – PSB (közigazgatási szolgáltatásbróker) létrehozás és kiépítése. A Szociális és Családügyi Minisztériumon belül 1999-ben hozták létre a Reach Ügynökséget, melynek legfıbb feladata az e-kormányzathoz kapcsolódó tevékenységek kidolgozása, végrehajtása lett. Ennek keretében jött létre a közigazgatási szolgáltatásbróker a „Public Service Broker” intézménye, mely közvetítıi, segítségnyújtó funkciót tölt be. A PSB alapkoncepciója az volt, hogy egy web-alapú rendszert hozzanak létre, amely integrálja mind a helyi, mind a központi közigazgatás szolgáltatásait, mégpedig egy belépési-ponton („one-stop”). A tanulmány utolsó fejezete összefoglalja az ír eközigazgatási interoperabilitási keretrendszer kiépítése során tapasztaltakat, és megfogalmaz néhány megfontolásra érdemes javaslatot a magyar keretrendszer kialakítására vonatkozóan.

Típus (Type) Forrás (Source) Kapcsolat (Relation) Terület (Coverage) Létrehozó (Creator) Kiadó (Publisher) Résztvevı (Contributor) Jogok (Rights) Dátum (Date) Formátum (Format) Azonosító (Identifier) Nyelv (Language) Verzió Státusz Fájlnév Méret Ár Felhasználási jogok

Szöveg

e-Közigazgatási Keretrendszer Kialakítása projekt Miniszterelnöki Hivatal KOPINT-DATORG Infokommunikációs Zártkörően Mőködı Részvénytársaság (Kopint-Datorg Zrt.) 2008.06.12.

magyar

V2 végleges EKK_ekozig_nemzetkozi_gyak_IR_080612_V2.doc

A dokumentum neve

A dokumentum készítıjének neve A dokumentum jóváhagyójának neve A dokumentum készítésének dátuma Verziószám Összes oldalszám A projekt azonosítója

Az e-közigazgatás releváns ismereteinek, nemzetközi gyakorlatának és megoldásainak győjtése: ÍRORSZÁG KOPINT-DATORG Infokommunikációs Zártkörően Mőködı Részvénytársaság (Kopint-Datorg Zrt.) 2008.06.12. 2 107 EKK_ekozig

Tartalomjegyzék TARTALOMJEGYZÉK ............................................................................................................................................ 5 1. BEVEZETÉS........................................................................................................................................................... 7 2. AZ ÍR E-KÖZIGAZGATÁS FEJLİDÉSÉNEK TÖRTÉNETI ÁTTEKINTÉSE ........................................... 8 2.1. TÖRTÉNETI ÁTTEKINTÉS ..................................................................................................................................... 8 2.2. AZ E-KÖZIGAZGATÁS SZEREPLİI ...................................................................................................................... 11 2.3. AZ E-KÖZIGAZGATÁS INFRASTRUKTÚRÁJA ...................................................................................................... 13 2.3.1. Kormányzati portálok Írországban.......................................................................................................... 13 2.3.2. A közigazgatási szolgáltatás-bróker rendszer (Public Services Broker – PSB) ..................................... 16 2.3.3. Azonosítás és hitelesítés, „ügyfélkapu”................................................................................................... 16 2.3.4. E-kormányzati gerinchálózat................................................................................................................... 18 2.3.5. Hatósági ügyintézés................................................................................................................................. 18 2.3.6. Egyéb fontos e-kormányzati szolgáltatások ............................................................................................. 18 3. KERETRENDSZEREK ÉS KAPCSOLÓDÓ SZABVÁNYTÁRAK BEMUTATÁSA .................................. 19 3.1. KERETRENDSZEREK ÁTTEKINTÉSE ................................................................................................................... 19 3.2. AZ E-KORMÁNYZAT INTEROPERABILITÁSI KERETRENDSZERE .......................................................................... 20 3.2.1. A REACH projekt..................................................................................................................................... 20 3.2.2. A Közigazgatási Szolgáltatás-Bróker (Public Services Broker – PSB) fejlıdése ................................... 21 3.3. REACH INTEROPERABILITÁSI AJÁNLÁSOK ....................................................................................................... 29 3.3.1 Bevezetés................................................................................................................................................... 30 3.3.1.1 Kontextus.............................................................................................................................................................30 3.3.1.2 Célkitőzés ............................................................................................................................................................30 3.3.1.3 Hatókör................................................................................................................................................................30 3.3.1.4 Célközönség ........................................................................................................................................................30 3.3.1.5 A dokumentum státusa ........................................................................................................................................30

3.3.2 Áttekintés .................................................................................................................................................. 30 3.3.2.1 Interoperabilitási alapelvek..................................................................................................................................30 3.3.2.2 Interoperabilitási keretrendszer............................................................................................................................32

3.3.3 Transzport RIG-ek .................................................................................................................................... 33 3.3.3.1 Alapelvek.............................................................................................................................................................33 3.3.3.2 Transzport Adapterek ..........................................................................................................................................33 3.3.3.3 Bizalmas hosztok.................................................................................................................................................34 3.3.3.4 Hálózati összekapcsolhatóság..............................................................................................................................34

3.3.4 Üzenetközvetítı RIG-ek ............................................................................................................................ 34 3.3.4.1 Alapelvek.............................................................................................................................................................34 3.3.4.2 rig0100.................................................................................................................................................................35 3.3.4.3 Egyidejőség .........................................................................................................................................................36 3.3.4.4 Összekapcsolási minták .......................................................................................................................................36 3.3.4.5 Üzenetközvetítı minták .......................................................................................................................................36 3.3.4.6 A szolgáltatás jellemzık minısége ......................................................................................................................36 3.3.4.7 Mit fog a PSB tenni minden üzenettel .................................................................................................................37

3.3.5. Szolgáltatás definíciós RIG-ek................................................................................................................. 37 3.3.5.1 Alapelvek.............................................................................................................................................................37 3.3.5.2 Szolgáltatás interfész profilok .............................................................................................................................37 3.3.5.3 Szolgáltatás együttmőködési minták....................................................................................................................38 3.3.5.4 Web szolgáltatások ..............................................................................................................................................38

3.3.6. Adat/Tartalom RIG-ek ............................................................................................................................. 39 3.3.6.1 Alapelvek.............................................................................................................................................................39 3.3.6.2 Üzenet RIG-ek.....................................................................................................................................................39

3.3.7. Üzleti RIG-ek ........................................................................................................................................... 39 3.3.7.1 Alapelvek.............................................................................................................................................................39

3.3.8. XML ajánlások......................................................................................................................................... 40 3.3.8.1 Alapelvek.............................................................................................................................................................40 3.3.8.2. Alapvetı RIG-ek.................................................................................................................................................40

3.3.9. Következtetések........................................................................................................................................ 41

3.3.10. Függelék: Bevezetés az XML használatába a PSB-n belül.................................................................... 41 3.4. A BRÓKER ARCHITEKTÚRA MODELL BEMUTATÁSA......................................................................................... 44 3.4.1. Összefoglalás........................................................................................................................................... 45 3.4.2. Mi az a PSB? ........................................................................................................................................... 45 3.4.3. Architektúra felépítési elvek .................................................................................................................... 47 3.4.3.1. Általános alapelvek.............................................................................................................................................47 3.4.3.2. Integrációs elvek.................................................................................................................................................48

3.4.4. Architektúra felépítési nézetek................................................................................................................. 48 3.4.4.1. Integrációs nézetek .............................................................................................................................................48 3.4.4.2. Felhasználói felületi nézetek...............................................................................................................................50 3.4.4.3. Egyéb nézetek.....................................................................................................................................................50

3.5.AZ ÍR KÖZSZOLGÁLTATÁSOK METAADAT SZABVÁNYA ................................................................................... 67 4. HASZNOSÍTHATÓ TAPASZTALATOK ......................................................................................................... 68 MELLÉKLETEK ..................................................................................................................................................... 71 1. MELLÉKLET: AZ ÍR KÖZSZOLGÁLTATÁSOK METAADAT SZABVÁNYA ................................................................ 73 SZAKIRODALMI HIVATKOZÁSOK .................................................................................................................. 98 RÖVIDÍTÉSGYŐJTEMÉNY................................................................................................................................ 102 FOGALOMTÁR ..................................................................................................................................................... 104

Írország

1. Bevezetés Jelen tanulmány célja, hogy áttekintést adjon az ír e-kormányzati keretrendszer kialakatásának legjelentısebb lépéseirıl, ill. a rendszer legfontosabb elemeirıl. A második fejezet elsı részében rövid történeti leírást adunk az ír e-közigazgatás legfontosabb mérföldköveirıl, az 1999-ben meghírdetett állami Akciótervtıl a 2002-ben megfogalmazott „Új kapcsolatok – Stratégia az információs társadalom potenciáljának realizálására” jelentésig. A fejezet második részében ismertetjük az ír e-közigazgatás legfontosabb szereplıit, feladataik rövid bemutatásával. Ezt követıen részletesebben is bemutatjuk az ír e-közigazgatás infrastruktúráját, így a kormányzati portálokat (www.citizeninformation.ie, www.basis.ie, www.reachservices.ie), a Reach Ügynökséget, a Közigazgatási Szolgáltatás Brókert (PSB), az e-kormányzati gerinchálózatot, a hatósági ügyintézést és az e-közbeszerzést segítı rendszereket. A harmadik fejezetben elıször áttekintjük, hogy milyen keretrendszerek kerültek kialakításra eddig Írországban, majd részletesen ismertetjük az ír e-kormányzati interoperabilitási keretrendszert. Kitérünk a Reach projekt legmeghatározóbb szakaszaira és vázoljuk a Közigazgatsái Szolgáltatás Bróker (Public Service Broker - PSB), mint az intézményközi adatkapcsolat alapját adó rendszer felépítését. Az ír e-kormányzat egyik nagyszabású projektje volt a Public Service Broker – PSB (közigazgatási szolgáltatás-bróker) létrehozás és kiépítése. A Szociális és Családügyi Minisztériumon belül 1999-ben hozták létre a Reach Ügynökséget, melynek legfıbb feladata az e-kormányzathoz kapcsolódó tevékenységek kidolgozása, végrehajtása lett. Ennek keretében jött létre a közigazgatási szolgáltatás-bróker a „Public Service Broker” intézménye, mely közvetítıi, segítségnyújtó funkciót tölt be. A PSB alapkoncepciója az volt, hogy egy web-alapú rendszert hozzanak létre, amely integrálja mind a helyi, mind a központi közigazgatás szolgáltatásait, mégpedig egy belépési-ponton („one-stop”). A harmadik fejezet utolsó részében részletesen ismertetjük az ír interoperabilitási keretrendszer alapdokumentumát a „Reach Interoperability Guidlines (RIGs)” ajánlást, valamint a PSB felépítését felvázoló „Broker Architecural Model” címő leírást. A fejezet végén összefoglaljuk az ír közszolgáltatások metaadat szabványának (The Irish Public Service Metadata Standard - IPSMS) legfontosabb jellemzıit. A tanulmány utolsó fejezetében összefoglaljuk az ír e-közigazgatási interoperabilitási keretrendszer kiépítése során tapasztaltakat, és megfogalmazunk néhány megfontolásra érdemes javaslatot a magyar keretrendszer kialakítására vonatkozóan.

7

2. Az ír e-közigazgatás fejlıdésének történeti áttekintése 2.1. Történeti áttekintés Az Információs Társadalom megvalósítására irányuló elsı állami Akciótervet az ír kormány 1999 januárjában hozta nyilvánosságra. Ezt megelızıen már az 1994-1999. évi Nemzeti Fejlesztési Tervben meghirdették a kommunikációs infrastruktúra és szolgáltatások fejlesztésének programját. 1996-ban az IKT alkalmazásával kapcsolatos átfogó koncepció kidolgozásával a kormány az újonnan létrehozott „Information Society Steering Committee”-t, vagyis az „Információs Társadalom Irányítási Bizottság”-ot bízta meg. Az Irányítási Bizottság készítette el 1997 márciusára az információs társadalom megteremtésével kapcsolatos indító stratégiai programot (Information Society Ireland: Strategy for Action). Az információs társadalom megvalósulásának öt pillérét a következıkben határozta meg: 1 1. Tudatosság, széleskörő Internet-hozzáférés 2. Infrastruktúra biztosítása 3. IKT-vel átitatott oktatás 4. Üzleti szektor, vállalkozások bevonása az információs társadalom folyamataiba 5. Kormányzati szektor modernizációja A felmerült igények alapján, a szakminisztériumok és a kormányzati programok közötti koordináció és összhang megteremtése céljával, 1997 májusában két, az információs társadalom megvalósításában kiemelt szerepet játszó bizottságot hoztak létre:2


az „Információs Társadalom Bizottság”-ot (Information Society Commission - ISC) és




a „Tárcaközi Megvalósítási Csoport az Információs Társadalomért” nevő munkacsoportot (Interdepartmental Implementation Group for the Information Society).

A „Információs Társadalom Bizottság”-ot az ír Miniszterelnöki Hivatal (Taoiseach) hozta létre, melynek feladatai a következıképpen foglalhatóak össze:3


Írország eredményeinek, helyének, helyzetének meghatározása, elemzése és értékelése, nemzetközi összehasonlításban is, az Információs Társadalom fejlıdése/fejlesztése szempontjából.




Tanácsadói és útmutatói tevékenységgel segíteni a kormányt abban, hogy a legjobb utat és a legjobb eszközöket választhassa az Információs Társadalom mind teljesebb kibontakoztatása érdekében.

1

INFORMATION SOCIETY WORLD PROGRESS REPORT 2004: A VILÁG ELİREHALADÁSA AZ INFORMÁCIÓS TÁRSADALOM TERÉN 2004-BEN MELLÉKLET, BME-UNESCO Információs Társadalom- és Trendkutató Központjának

(ITTK) kutatócsoportja, Budapest, 2004. október – 2005. március, http://www.informaciostarsadalom.hu/web/docs/WPR_2004_melleklet_v2.pdf 2 Az infokommunikáció kormányzati irányításának nemzetközi tapasztalatai: intézmények, az államigazgatás kapcsolatai a vállalatokkal és a lakossággal, KOPINT-DATORG Konjunktúra Kutatási Alapítvány, Budapest, 2002. március 28. 3 Az infokommunikáció kormányzati irányításának nemzetközi tapasztalatai, KOPINT-DATORG Rt., Készült a Miniszterelnöki Hivatal megbízásából, Budapest, 2000. április 8

Írország




Elımozdítsa az ICT mind szélesebb körő megismertetését, lényegének és hasznosságának a felismerését és elfogadását a lakosság és az üzleti világ valamennyi szegmensében.

A Bizottság közvetlenül a Miniszterelnöki Hivatalnak teszi meg jelentéseit. Tagjai a magánés a közületi szektor prominens képviselıi. A Bizottság munkáját az általa létrehozott tanácsadó testületek segítik. Az ismeretek terjesztésére alakult tanácsadói csoport (Awareness Advisery Group) feladata az, hogy kiválassza a számba jövı lehetséges stratégiák közül azokat, amelyek a leghatékonyabban alkalmazhatóak egyrészt a lakosság, másrészt az üzleti világ ICTtudásszintjének az emelésére. A szintmérı és kutatás-tanácsadói csoport (Benchmarking and Research Advisory Group) munkája által mérettetik meg Írország sikeressége az információs társadalom megvalósításában. A kutatások célja egyrészt a belföldi eredmények felmérése, másrészt azok minél megbízhatóbb mérce szerinti összevetése a nemzetközi tapasztalatokkal. Írország helyzetének meghatározása és annak megállapítása, hogy helyezése a ranglistán miként javítható tovább. A „Tárcaközi Megvalósítási Csoport az Információs Társadalomért” koordinálja a minisztériumoknak az információs társadalommal kapcsolatos konkrét programjait, azok megvalósítását. Ennyiben az információs társadalom építésének a motorja. 1999 januárjában a kormány - az elızetes anyagok, és fıként a „Tárcaközi Megvalósítási Csoport” által kidolgozott tervezet alapján - közzé tette az információs társadalom megvalósításának részletes programját és menetrendjét tartalmazó Implementing the Information Society in Ireland: An Action Plan (Információs Társadalom Megvalósítása Írországban) akciótervet. Az „Akcióterv” fı célja az volt, hogy Írország az információs társadalomban minél hamarabb vezetı szerephez jusson. A kormányzat részérıl a megoldandó kulcskérdés a közszolgálati tevékenységek elektronikus úton történı kiszolgálása. Az akcióterv megvalósítását egy felsıvezetıi szintő tárcaközi bizottság ellenırzi. Ezen akcióterv három síkon kívánja megvalósítani az elektronikus kormányzatot, melyek az alábbiak:4 1. Információs szolgáltatások a kormányzat minden szintjén. Ezen belül elsısorban a kormányzati honlapok fejlesztése (információk frissítése) a cél. Két különleges adatbázist hoznak létre (a magánszemélyek és a cégek tevékenységére koncentrálva), továbbá egy „címtár” kerül kialakításra, amelyben a kormányzati szolgáltatások postai és e-mail címeit, illetve fax- és telefonszámát lehet majd elérni. 2. Interaktív szolgáltatások, olyan (önálló) projektek, amelyek az állampolgárok és az üzleti szféra számára PKI-t és az internetre alapuló technológiát alkalmazó, interaktív szolgáltatásokat biztosítanak. Ilyenek lehetnek például: a konzisztens alkalmazási felületek, elektronikus aláírások, regisztráció, tanúsítási eljárások kidolgozása szervezetközi szabványosítással, e-kormányzati rendszerek (adó be/visszafizetés, 4

A Magyar Információs Társadalom Stratégia elektronikus aláírás részstratégiája, Informatikai és Hírközlési Minisztérium, 2003. október http://www.emagyarorszag.hu//kepek/upload/2007-06/e_alairas_1006.pdf

9

kliens-információk keresése), intranetek (biztonságos interaktív adatbázisok és e-mail szolgáltatók), közszolgálat, egészségügy, önkormányzatok, oktatás, törvénykezés, elektronikus kereskedelmi rendszerek (beleértve cég, illetve földtulajdon regisztrációt). 3. Integrált szolgáltatások, amelyek alatt jövıbeli – magas fokon integrált – szolgáltatásokat értenek az élet (üzleti, magán – REACH projekt) valós eseményeire koncentrálva (születés, kormányzati segély, cégalapítás, házasság, stb.). A feladatokhoz rendelt anyagi erıforrásokat a Miniszterelnöki Hivatal az illetékes minisztériumokkal együtt határozta meg. Az Akció Terv minden szakaszának megvalósítása a Miniszterelnöki Hivatal és a minisztériumok közötti, illetve a minisztériumok egymásközti együttmőködésén alapult. Az ír kormányzat 1999-ben állította fel a Reach Agency-t, melynek legfıbb feladata az ekormányzathoz kapcsolódó tevékenységek kidolgozása, végrehajtása lett. Ennek keretében hozta létre a közigazgatási szolgáltatás-brókert a „Public Service Broker” intézményét, mely közvetítıi, segítségnyújtó funkciót tölt be. A Reach Agency stratégiák, jelentések elkészítésében egyaránt részt vett, de az egyablakos ügyintézés kialakításában, személyre szóló azonosítószám kidolgozásában szintén szerepet kapott. A Reach Agency szoros együttmőködésben dolgozott a Miniszterelnöki Hivatal irányítása alatt álló Információs Társadalom Egységgel és a Pénzügyminisztériummal. 2002-ben új nemzeti e-kormányzat stratégiát fogalmaztak meg az „Új kapcsolatok – Stratégia az információs társadalom potenciáljának realizálására” (New Connection – A Strategy to realise the potential of the Infromation Society) jelentésben, melyet 2002 márciusában tettek közzé. Ennek célja központi fókusz létrehozása az összes központi egység és szervezet részére a közszolgálatok kezelésérıl szóló törvénynek megfelelı stratégia nyilatkozataik révén. A dokumentum (New Connections) az alábbi célterületek megvalósítását tekinti kulcsfontosságúnak:5








Infrastruktúra biztosítása, Szükséges szabályozási környezet kialakítása, e-Kormányzat, e-Business, Kutatás-fejlesztés, Élethosszig tartó tanulás, Társadalmi integráció (e-Inclusion).

Írország következı e-kormányzati kezdeményezése 2004-ben indult el, amikor a Miniszterelnöki Hivatal irányítása alatt álló Információs Társadalom Egység az elkezdett folyamatok felgyorsítását határozta el és az eCabinet rendszer életbeléptetése mellett döntött. Ennek értelmében valamennyi kormányhivatal feladata, hogy jelentéseit papíralapú dokumentáció helyett elektronikus úton küldje el a Miniszterelnöki Hivatal felé.

5

INFORMATION SOCIETY WORLD PROGRESS REPORT 2004: A VILÁG ELİREHALADÁSA AZ INFORMÁCIÓS TÁRSADALOM TERÉN 2004-BEN MELLÉKLET, BME-UNESCO Információs Társadalom- és Trendkutató Központjának

(ITTK) kutatócsoportja, Budapest, 2004. október – 2005. március, http://www.informaciostarsadalom.hu/web/docs/WPR_2004_melleklet_v2.pdf 10

Írország 6

2.2. Az e-közigazgatás szereplıi

Stratégia:
Miniszterelnöki Hivatal (Irish Prime Minister) - Department of Taoiseach: az információs társadalom és az e-közigazgatás stratégia közvetlen felelıse. A Miniszterelnöki Hivatal illetve a Miniszterelnök az Információs Társadalom és az ekormányzati politika és stratégia közvetlen felelıse. A Hivatal az e-kormányzat irányításának és a prioritások megjelölésének csúcsintézménye, kijelöli az átfogó célokat, kialakítja a szakpolitika általános kereteit, valamint megteremti a stratégiai fejlesztési területekhez szükséges ösztönzési eszközöket.


Információs Társadalomért felelıs Miniszter - Minister of State with responsibility for the Information Society: felelıs az irányelvek koordinálásáért, hogy biztosítsák az információs társadalom folyamatos fejlıdését Írországban. Az információs társadalom-kérdésekben képviseli Írországot az európai és más nemzetközi fórumokon. A Miniszterelnöki Hivatalon belül a miniszter a kormányzaton belüli Információs Társadalom és az e-kormányzat tevékenység folyamatos fejlesztésének, elırehaladásának, a politika koordinálásának, a nemzeti politikák végrehajtásának és monitorozásának felelıse.




Információs Társadalom Irányító Egység - Information Society Policy Unit (ISPU): a Miniszterelnöki Hivatalon belül mőködik. Az információs társadalom területek implementációjának fejlesztéséért, koordinálásáért és vezetéséért felelıs. Az ISPU a Miniszterelnöki Hivatalon belül az Információs Társadalom-„forgatókönyv” végrehajtásának hajtóereje. Az ISPU egyben a Kabinet Információs Társadalom Bizottságának és az Államtitkárok e-Stratégia Csoportjának titkárságaként is mőködik, valamint segíti a Szakállamtitkári e-Kormányzati Végrehajtó Csoport munkáját.




az információs társadalom stratégiáért felelıs Kabinet Információs Társadalom Bizottsága - Cabinet Committe on the Information Society: Ez a Bizottság határozza meg, hagyja jóvá és monitorozza az Információs Társadalom-stratégiát. A Bizottságot a miniszterelnök vezeti, tagja több miniszter és esetenként az Információs Társadalomért felelıs államminiszter hívja össze.




az Államtitkárok e-Stratégia Csoportja - eStrategy Group of Secretaries General, mely az elıbbi munkáját segíti, és meghatározza a nemzeti e-stratégia témáit.




Vezetési Szervezet és Fejlesztési Központ - Centre for Management Organisation and Development (CMOD): a Pénzügyminisztériumon belül mőködik és általános stratégiai szerepe van az ICT területén, a stratégiai iránnyal, a közös szoláltatásokkal és infrastruktúrával kapcsolatban. Ezen kívül a Pénzügyminisztérium belsı ICTfejlesztéséért is felelıs.

Koordináció:
Információs Társadalomért felelıs Miniszter - Minister of State with responsibility for the Information Society: A miniszter az Információs Társadalommal kapcsolatosan a közigazgatáson belüli tevékenységek koordinálásának legfıbb felelıse. 6

Ireland, eGovernment Factsheets, European Communities, February 2008, http://www.epractice.eu/index.php?page=document.factsheets&cntr=12 11




Információs Társadalom Irányító Egység - Information Society Policy Unit: Az ISPU a Miniszterelnöki Hivatalon belül az Információs Társadalom-„forgatókönyv” koordinálásának hajtóereje.




Szakállamtitkári e-Kormányzati Végrehajtó Csoport - Assistant Secretaries eGovernment Implementation Group, mely az információs társadalmi direktívák minisztériumi implementációját ellenırzi

Megvalósítás:
Reach Ügynökség - Reach Agency: Az 1999-ben létrehozott szervezet feladata a Public Services Broker fejlesztése és mőködtetése. A Bróker az állampolgárok, az üzleti szféra és a közigazgatási intézmények közötti nagy volumenő, biztonságos tranzakciók megosztott szolgáltatási felületének kerete.


Minisztériumok és Ügynökségek - Government Departments and Agencies: Az egyes minisztériumok és szervezeteik a saját mőködési területeiken felelısek a specifikusan rájuk vonatkozó e-kormányzati stratégia megvalósításáért, valamint a kompetenciájukba tartozó projektek végrehajtásáért.

Támogatás:
Reach Ügynökség - Reach Agency


Információs Társadalom Irányító Egység - Information Society Policy Unit (ISPU)

Audit:
Számvevıszéki Hivatal és Legfıbb Auditor Hivatala - Office of the Comptroller and Auditor General: A Hivatal feladata a közigazgatási intézmények beszámolóinak auditálása és az arról szóló jelentés elkészítése, annak vizsgálata, hogy a köztestületek tranzakciói összhangban állnak-e a törvényi szabályozással, valamint, hogy a testületek gazdaságosan hasznosítják-e forrásaikat. Adatvédelem:
Adatvédelmi Biztos - Data Protection Commissioner: Felelıs az egyéneknek az Adatvédelmi Törvényben meghatározott jogai betartatásáért, érvényesíti az adatvizsgálati kötelezettségeket. A Biztost a kormány nevezi ki és funkcióit függetlenül gyakorolja. Egyéb:
Az Információ Biztos Hivatala - Office of the Information Commissioner: Fı feladata a köztestületek (public bodies) döntéseinek felülvizsgálata az Információs Szabadság Törvényének (FOI) alapján, s amennyiben szükséges, kötelezı erejő új határozatokat hoz. Regionális és helyi e-Kormányzat:
Helyi önkormányzati Számítógép Szolgáltatási Testület - Local Government Computer Services Board (LGSCB): Az LGCSB olyan központi állami szervezet, amely szorosan együttmőködik a helyi közigazgatási szervezetekkel. Az a feladata, hogy a helyi intézmények számára az IKT-val kapcsolatos igényeikkel kapcsolatosan a lehetı legjobb megoldásokat kínálja, segítse ıket a megfelelı mőködési stratégia

12

Írország

kialakításában, s hogy megoldásaikban hozzájáruljanak az általános e-kormányzati forgatókönyv megvalósításához.


Helyi közigazgatási Auditálási Szolgálat - Local Government Audit Services (LAGS): Az LGAS egy külsı auditálási szolgáltatás, amely független hitelességet biztosít a helyi szervezetek és testületek pénzügyi vizsgálatában.

2.3. Az e-közigazgatás infrastruktúrája Írországban az e-közigazgatási feladatok végrehajtásában állami ügynökségek (state agency) és állami támogatásban részesülı egyéb szervezetek (teljesen vagy részben állami tulajdonú társaságok és szervezetek – state sponsored body) is részt vesznek. A központi informatikai közmő mőködtetése és a hozzá kapcsolódó szolgáltatások ellátása terén a következıkben ismertetendı fı szereplık és funkciók találhatók. 2.3.1. Kormányzati portálok Írországban Háromféle kormányzati portált mőködtetnek Írországban: A) A lakosság tájékoztatását, az ügyintézések élethelyzetszerő csoportosításán keresztül elıször az OASIS (Online Access to State Information and Services) projekt keretében oldották meg, a portál www.oasis.gov.ie címen 2001 áprilisában kezdett mőködni. 2006 novemberében a portált megújították, és azóta, az Állampolgári Tájékoztatás Tanácsa (Citizen Information Board) szakmai irányítása alatt Citizens Information néven (www.citizensinformation.ie) érhetı el. A Tanács – állami támogatással mőködı szervezetként és a Szociális és Családügyi Minisztérium (www.dsfa.ie) felügyelete alatt – többcsatornás tájékoztatást lát el: a portálon kívül telefonon és személyesen is kérhetı információ az állampolgárokat érintı ügyekrıl. Ez utóbbi feladatot az állampolgári információs központok (Citizen Information Centres) országos hálózatán keresztül látja el. A portál 14 kategóriába sorolva ismerteti az egyes élethelyzetekben felmerülı ügyeket, az azzal kapcsolatos információkat és a kapcsolódó formanyomtatványok letöltésére is lehetıséget nyújt. Az Citizens Information (OASIS)-on található információk, az „élet eseményei” szerint:
Születés, Család és Kapcsolatok
Fogyasztói ügyek
Halálozás és Gyász
Oktatás
Foglalkoztatás
Környezetvédelem
Ír kormányzás
Egészség
Lakás
Igazságszolgáltatás
Pénzügyek, Adó
Ki- és bevándorlás
Szociálpolitika
Utazás

13

B) A még 2000-ben elindított BASIS (Business Access to State Information and Services) projekt eredményeként 2001 májusától mőködik a vállalati szféra számára közigazgatási információkat és szolgáltatásokat kínáló portál (www.basis.ie). A portál fejlesztését és a tartalomszolgáltatást a Vállalkozási, Kereskedelmi és Foglalkoztatási Minisztérium (DETE, www.entemp.ie) alatt mőködı állami ügynökség végzi. A portál tematikusan, a konkrét szükségletekbıl kiinduló élethelyzet csoportosításban tartalmaz információkat, linkeket, letölthetı formanyomtatványokat, átirányítást az online szolgáltatásokhoz, intézmény/szolgáltató keresı rendszert, hírlevelet stb. Az BASIS-on található információk, az „élet eseményei” szerint:
Vállalkozásindítás
Finanszírozás
Jogi és szabályozási kérdések
Üzleti mőveletek és kereskedelem
Épülettel és környezettel kapcsolatos kérdések
Foglalkoztatási kérdések
Adózás
Visszatérítések és egyéb kötelezettségek
Innováció és termékfejlesztés
Üzlet kiterjesztése
Kormányzati tenderek
Vállalkozás bezárása, eladása A portál könnyő hozzáférést biztosít a helyi kormányzatok szolgáltatásaihoz (adó, oktatás, vállalkozás), az adóhivatal szolgáltatásaihoz, a kormányzati közbeszerzésekhez, a leggyakrabban használt nyomtatványokhoz, megadva mindenhol a témával kapcsolatos kapcsolódási részleteket. 2001 végén indították el a kormányzati hívásközpont mőködését, amely telefonon keresztül biztosítja a kapcsolódást az alapinformációkra és az egyes minisztériumok, testületek szakértıihez. C) A Reachservices portál (www.reachservices.ie) már egy késıbbi fázisban, de a központi kormányzati infrastruktúra meghatározó elemeként került beindításra 2002 áprilisában. Fı feladata az, hogy a közigazgatási szolgáltatásokat és információkat, valamint az ezeket felhasználókat egyetlen felületen találkoztassa (one-stop government). A portálon fı élethelyzetek köré csoportosítva rendezték az információkat, bemutatva nem csupán a közigazgatási szolgáltatások széles körét, hanem külön is csoportosítva az interaktív, online elérhetı szolgáltatásokat. Ez utóbbiak körében a letölthetı és online visszaküldhetı nyomtatványok mellett a portálon – megfelelı regisztrálást, majd bejelentkezést követıen – biztonságos átirányítással eljuthatunk az ügyintézéshez is. A portál maga is folyamatos fejlesztés alatt áll. 2005 májusától nyílik csak lehetıség – az ún. közigazgatási szolgáltatás-bróker (PSB) rendszer aktiválását követıen – az azonosítást igénylı szolgáltatások és az elektronikus fizetés igénybe vételére a portálon keresztül. A portál, más szavakkal, a PSB felhasználói interfésze. A portál 3 szinten szolgáltat információkat:
Az elsı szinten egyirányú információnyújtás történik, ahol az ügyfél tudomást szerezhet bizonyos kormányzati intézkedésekrıl, pl. jogszabályokról.
A második szinten található szolgáltatások interaktívak: itt már adatok kommunikálása történik a digitális igazolványt használók között.

14

Írország




A harmadik szinten a szolgáltatások teljes mértékben integráltak. Ezeknek a programoknak a telepítése folyamatos, de már mőködnek bizonyos területen.

A REACH Ügynökség: A Reachservices portált mőködtetı Reach Ügynökséget (www.reach.ie) 1999-ben alapították. Az állami ügynökség a Szociális és Családügyi Minisztérium (www.dsfa.ie) felügyelete alatt mőködött, igazgatója pedig az államtitkárnak tartozott beszámolással. Az Ügynökség szakmai irányítását egy ún. tanácsadó bizottság (Advisory Board) kontrollálta, amelybe több minisztérium és országos hatáskörő szervezet delegált tagot. 2007 májusa óta a bizottság a Szociális és Családügyi Minisztérium (Department of Social and Family Affairs), az Igazságügyi, Egyenlıségi és Törvényreform Minisztérium (Department of Justice, Equality and Law Reform), a Mezıgazdasági Minisztérium (Department of Agriculture and Food), a Környezetvédelmi és Önkormányzati Minisztérium (Department of Environment and Local Government), képviselıibıl és az Egészségügyi Szolgáltatások (The Health Services Executive) és az Állami bevételek Biztosaiból (Revenue Commissioners) tevıdött össze. 2008. április 1-tıl a REACH összes funkciója és kötelezettsége fölött a Pénzügyminisztérium vette át az irányítást, és a felelısség a Módszertani Osztályhoz (Technology Policy Division) került. Ennek köszönhetıen a www.reach.ie portál nem elérhetı, így a korábban itt közzétett interoperabilitással ill. PSB-vel kapcsolatos anyagok sem hozzáférhetıek ezen a weboldalon. A REACH feladata a kormányzati szolgáltatások továbbfejlesztése, az integrált ügyfél-centrikus szolgáltatások bevezetése volt valamennyi szektorban, valamint az ellenırzés erısítése az államilag finanszírozott szolgáltatásoknál a visszaélések, csalások elkerülésére. A REACH Ügynökségnek kellett tovább fejlesztenie, bıvítenie a személyi azonosító szám (Personal Public Service Number – PPSN) és a közigazgatási szolgáltatási kártya (Public Service Card - PSC) alkalmazását. A Reach feladat volt a közigazgatási szolgáltatás-bróker, Public Services Broker (PSB) kifejlesztése és mőködtetése is.

A Reach kormányzati struktúrája

1. ábra Forrás: eGovernment, John Purcell, Comptroller and Auditor General, 19 October 2007, http://www.audgen.gov.ie/documents/vfmreports/58_eGovernment.pdf

15

2.3.2. A közigazgatási szolgáltatás-bróker rendszer (Public Services Broker – PSB) A PSB modell koncepcionális alapját még 2000 májusában fogadta el az ír kormányzat és a REACH Ügynökség feladatául szánta a konkrét megtervezést, kifejlesztetést és kivitelezést. Ez több év csúszás után, végül is 2004 közepén jutott pilot-, és 2005 tavaszán éles mőködési fázisba. A közigazgatási szolgáltatás-közvetítés (bróker), a PSB az integrált szolgáltatásnyújtás eszköze, amely mind a szolgáltató hatóságokat és szervezeteket, mind az egyes igénybevételi csatornákat (web, telefon, személyes ügyfélszolgálat) egybefogja. Az ügyfél – tetszıleges elérési csatornán bejelentkezve – azonosítás és hitelesítés után, élethelyzetek szerint csoportosítva juthat el az egyes közigazgatási szolgáltatásokig. Az állampolgárok megfelelı regisztráció után saját számlát (fakkot) és értesítési tárhelyet kapnak. Felhasználónév és jelszó beírása után az ügyfelek hozzáférhetnek saját adataikhoz, leveleikhez és mentett dokumentumaikhoz, s a központi azonosítást követıen már más hatóságoknál is intézhetik ügyeiket. Az egykapus közigazgatás megvalósításának feltétele, hogy az egyes állami intézmények és szolgáltatók között biztonságos adatkapcsolat jöjjön létre. Ezért fejlesztették ki a PSB egyik alapelemeként, a SOA (Services Oriented Architecture) alapelvre építve az intézményközi adatkapcsolat rendszerét (Inter-Agency Data Exchange, IADE). Ez egy olyan központi rendszer, amely széles körben alkalmazott XML szabványokra, standard adattovábbítási protokollra, a kapcsolódást biztosító szoftverekre épül. Lehetıvé teszi, hogy különbözı számítógépes és üzleti rendszerek együttmőködjenek, s mindezt alacsony költségek mellett. Lényege, hogy bármely intézmény, amely összekapcsolódik a központi szolgáltató rendszerrel (PSB) egyben valamennyi a KR-hez csatlakozó más intézménnyel is adat és dokumentumforgalmat bonyolíthat le. Az üzenetkezelı központ (hub) XML üzeneteket közvetít a bekapcsolt intézmények rendszerei között. Valamennyi üzenet standard Reach-típusú XML „borítékba” kerül becsomagolásra. Az üzenetek a már említett IAMS rendszerben kerülnek továbbításra. 2005. évi debütálása óta a PSB rendszer keretében négy fontos, bevált gyakorlatnak tekinthetı szolgáltatást tettek elérhetıvé: 1) RASER - agrárexport támogatások a Mezıgazdasági Minisztérium és az Adóhivatal közötti adatkapcsolat megvalósításával 2) JSMS - a büntetıjog területén a bíróság és a rendırség közötti adatkapcsolattal 3) DEPS - az Anyakönyvi Hivatal értesítése az elhalálozási esetekrıl az illetékes hivatalok részére 4) PAYE - Paye on-line. A PSB rendszerbe való bejelentkezés, valamint a PPSN kért számjegyei megadása után közvetlen hozzáférés nyílik az adóhivatal ROS portáljához, amelyen keresztül számos adóhatósággal kapcsolatos ügy on-line elintézhetı (pl. a személyes adónyilvántartás megtekintése, adóvisszaigénylés, lakcímváltozás bejelentése, adók elektronikus fizetése stb.) 2.3.3. Azonosítás és hitelesítés, „ügyfélkapu” Írországban a központi e-kormányzati infrastruktúra és az integrált közigazgatási szolgáltatások koncepciója a közigazgatási szolgáltatás-bróker (Public Services Broker, PSB) modell köré épült. A PSB-rendszer azonosítási és hitelesítési szolgáltatást nyújt az elektronikus közigazgatási szolgáltatásokhoz. Minden születéskor kiosztanak egy személyi

16

Írország

azonosító számot (Personal Public Service Number, PPSN), ami eredetileg adó és TB azonosításra is szolgált, de ma már valamennyi közigazgatási szolgáltatás esetében biztosítja a személyi azonosítást. A PSB-rendszerben a hitelesítés a PPSN felhasználásával mőködik. A PPSN nyilvántartást a Szociális és Családügyi Minisztérium (www.dsfa.ie) egyik részlege végzi, míg a PSB-rendszer kifejlesztıje és mőködtetıje a szintén a Minisztérium felügyelete alatt mőködı már említett állami ügynökség, a REACH. Az elektronikus azonosítás céljából 2004. óta vizsgálják egy egységes közigazgatási szolgáltatás kártya (Public Service Card, PSC) kifejlesztését, ami egyelıre még nem került bevezetésre. A kormányzati szolgáltatások elérése az ún. eBroker (PSB) portál rendszeren keresztül lehetséges, mely lehetıvé teszi, hogy az elektronikus kormányzatot, mint egyetlen virtuális nagyvállalatot lehessen elérni egyetlen ponton, egyszeri bejelentkezéssel. Ehhez egy ún. szuper regisztrációs eljárást alkalmaznak, amely lehetıvé teszi az információk továbbítását az állampolgárok számára egy PKI-val (Public Key Infrastructure) védett széfbe, mely szintén az eBrokerben található.7 Az információ birtokosa továbbra is az állampolgár marad, aki eldöntheti, hogy mikor és milyen elektronikus szolgáltatások számára teszi elérhetıvé ezeket az adatokat. A felhasználók például dönthetnek úgy, hogy elküldik a digitális fényképüket a széfbe, majd útlevél vagy jogosítvány kiállításánál fogják azt felhasználni. A PKI adaptációja óta egy hitelesítés-szolgáltató szolgálja ki a teljes kormányzatot, és csak egy fajta (személyi) tanúsítványt adnak az állampolgárok számára. Szerepkör alapú tanúsítványok nem kerülnek kiosztásra, mivel ilyen információt tartalmazó adatbázissal már rendelkezik a kormányzat, és ilyen információt az állampolgárok eBroker széfjében is tárolni lehet. A kormányzat körében pedig csak szervezeti/minisztériumi szinten bocsátanak ki tanúsítványokat, egyénileg (egy személy részére) nem, mivel úgy találták, hogy erre nincs szükség. Az ír közigazgatás egyetlen kormányzati intranetet alkalmaz. Ez egy szabványos infrastruktúra, mely minisztérium közi e-mail szolgáltatás mellett, közös adattárak elérését is biztosítja a kormányzat számára. Az intranet már több éve üzemel, és jó alapot jelent a minisztériumok integrált elektronikus szolgáltatásainak továbbításához. A PSB a kormányzati intraneten keresztül kapcsolódik a minisztériumi információs rendszerekhez, valamint egy központi hitelesítı rendszerhez, amely a PKI technológiát is támogatja. A bizalmasságot a minisztériumok által már elfogadott titkosítási megoldásokkal valósították meg. A PSB az állampolgárnak az állammal való elektronikus kapcsolatot nyújtja és hozzáférhetıvé teszi létezı és tervezett különálló kormányzati minisztériumok alkalmazásait. Továbbá hitelesítési szolgáltatást nyújt a szolgáltatások számára, és a PSB megoldja az állampolgár azonosítását. A PSB több módon elérhetı, mint pl.: betárcsázás, WAP, digitális TV, nyilvános terminálok. Kiváló minıségő szolgáltatást internet Service Provider (ISP) menedzselt betárcsázással nyújtanak. Elfogadnak magáncégek által kibocsátott tanúsítványokat is. Ezeknek természetesen meg kell felelniük a kormányzati szabványoknak. Bár a zárt rendszerek egyes esetekben lehetıvé teszik a PKI-nál gyengébb hitelesítési technológiák alkalmazását, a PKI-ra mint kulcs

7

A Magyar Információs Társadalom Stratégia elektronikus aláírás részstratégiája, Informatikai és Hírközlési Minisztérium, 2003. október http://www.emagyarorszag.hu//kepek/upload/2007-06/e_alairas_1006.pdf

17

technológiára tekintenek a személyi számítógépeken és a mobil telefonhálózatokon keresztüli szolgáltatás elérésnél. 2.3.4. E-kormányzati gerinchálózat Írországban is kiépült a kormányhivatalok és állami intézmények egymás közötti biztonságos adatkapcsolatának lebonyolítására szolgáló belsı hálózat (GVPN – Government’s Virtual Private Network). A Reach Ügynökség az intézményközi adatáramlás biztosítására kifejlesztett és mőködtet egy megbízhatóan mőködı, központosított üzenetküldı rendszert (IAMS – Inter-Agency Messaging Service). 2.3.5. Hatósági ügyintézés Írországban a konkrét hatósági ügyintézést az egyes szakminisztériumok alá rendelt hivatalok, ügynökségek végzik. Például az e-közbeszerzés a Pénzügyminisztérium (www.finance.gov.ie) illetékes egysége (NPPPU) szakmai irányítása mellett és a Millstream Associates Limited informatikai cég mőszaki kivitelezésében és mőködtetésében kialakított rendszerben valósul meg 2001 decembere óta. Az eTenders hozzáférhetı a www.etenders.gov.ie címen. A közbeszerzéssel kapcsolatos információk egy helyrıl, az ír közbeszerzési portálról (www.procurement.ie) érhetık el. 2.3.6. Egyéb fontos e-kormányzati szolgáltatások Nagyteljesítményő keresımotor kifejlesztése a kormányzat megbízásából a dublini IQ Content cég által. A search.gov.ie címen elérhetı keresırendszer 2007 márciusától mőködik és egyelıre 13 kormányzati website indexált tartalmára terjed ki, de potenciálisan több mint 400 közigazgatási weboldalra kívánják kiterjeszteni. A cél az, hogy az egész ír közigazgatást lefedı, árnyalt keresırendszert alakítsanak ki, ami átfogó jellegő, ugyanakkor tehermentesíti is az egyes intézményeket az olykor igen költséges saját fejlesztések terhe alól. Megjegyzendı, hogy itt már támaszkodni lehetett az Ír Közigazgatási Metaadat Szabvány Rendszerre (Irish Public Service Metadata Standard – IPSMS, http://www.gov.ie/webstandards/default.htm ). eCabinet system – az ír Miniszterelnöki Hivatal (Taoiseach: www.taoiseach.gov.ie) belsı elektronikus (beleértve archívum, naptár, dokumentumkezelı) rendszere, amely 2006-ban a legjobb hazai fejlesztéseknek járó ír e-kormányzati díjban részesült.

18

Írország

3. Keretrendszerek és kapcsolódó szabványtárak bemutatása 3.1. Keretrendszerek áttekintése Az ír közigazgatás legfontosabb keretrendszerei: A.)

Vezetési Információs Keretrendszer (Management Information Framework – MIF http://www.bettergov.ie/eng/index.asp?devID=309; ManagementInformationFramework .rtf ) A MIF 1999-ben történt létrehozásával azt kívánták megvalósítani, hogy valamennyi minisztérium azonos szisztémájú rendszeres vezetési jelentésben közölje a különbözı források felosztásával és felhasználásával kapcsolatos döntéseit. A jelentéseknek pénzügyi és nem pénzügyi teljesítési információkat kell tartalmazniuk, valamint más hivatali rendszerekbıl származó információkat. A MIF-porjekt az állami források felhasználásának hatékonyságjavulását kívánja elérni:


a forrás-elosztási döntésekkel kapcsolatos információk és az indikátorok minıségének javítása révén,




a már elosztott források jobb kezelése révén,




a források felhasználásának fokozott átláthatóságának és kiszámíthatóságának segítségével.

A MIF ún. Központ Egysége biztosítja a segítséget a minisztériumok számára a keretrendszer követelményeinek teljesítésében. Ezt szolgálják a Teljesítési Indikátorok meghatározása, a beszámoló-, költség- és egyéb technikai jellegő példák prezentálása. Tanácsokért közvetlenül is lehet fordulni a Központ Egységhez. B.)

Ajánlások Üzleti Tervek Készítéséhez - Guidelines for the Preparation of Business Plans

C.) Ajánlások Stratégia Készítéséhez Minisztériumok számára - Guidelines on the Preparation of Strategy for Ministers and Secretaries General/Heads of Offices D.) Partnerkapcsolati Keretrendszer - Policy Framework for Public Private Partnership (PPP) in Ireland E.)

Nemzeti Képzési Keretrendszer (National Framework of Qualifications)

F.)

Interoperabilitási Keretrendszer (Reach Interoperability Guidlines – RIGs)

19

3.2. Az e-kormányzat interoperabilitási keretrendszere 8

3.2.1. A REACH projekt

Az ír kormány az uniós államok közül elsıként tett lépéseket a közigazgatási szolgáltatások elektronikus útra terelésében. Az ír reform azonban nem csak a szolgáltatásokhoz történı hozzáférést kívánta megkönnyíteni, hanem a közigazgatáson belüli adatforgalom ésszerőbb, gyorsabb, pontosabb és nem utolsó sorban törvényesebb módját. A REACH projekt keretében megvalósuló modernizáció elsı törvényi megjelenése az 1998-as Social Welfare Act (SWA) volt, amely megadta az egységes egyedi személyazonosító szám használatára jogosultak körét. Az egységes személyazonosító bevezetésének lehetıségét az 1998-as adatvédelmi törvény, majd az ezt módosító 2002-es törvény teremtette meg, ill. tette feltételektıl függıvé. Ennek megfelelıen kizárólag azok az állami és egyéb szervek jogosultak hozzáférni egy adott személy egységes azonosítójához, akiket a fenti, ill. hasonló rendelkezéseket tartalmazó újabb törvények feljogosítottak. Fontos megjegyezni, hogy az azonosító számot más szervek nem csak, hogy nem használhatják, de nem is ismerhetik, s azt semmilyen körülmények között nem kérhetik. A fent említett azonosító szám a Personal Public Service Number – PPSN. A számot a Szociális és Családügyi Minisztérium (Minister for Social and Family Affairs - MSFA) adja ki. Az MSFA gyakorol felügyeletet a PPSN használata felett is. Ennek keretében egyrészt vizsgálja, hogy a PPSN-t kizárólag közszolgáltatást nyújtó és a törvényben megjelölt szervek használhatják fel, másrészt felügyeli, a felhasználás törvényességét. Ennek folyományaként a PPSN, mint egységes személyazonosító szám felett nem egy önálló, dedikált szerv, hanem az MSFA és általános hatáskörénél fogva, az Adatvédelmi Hatóság (Data Protection Commissioner) gyakorol felügyeletet. A PPSN szám kiadása személyes megjelenés során, írásos (adatkezeléshez történı hozzájárulásra vonatkozó) nyilatkozat adása mellet, a megfelelı személyazonosító okmányok átadása után kerül sor. 2002 vége óta az újszülöttek PPS számát az anyakönyvezéskor generálják. A személyazonosítási modell (REACH) szereplıi: a polgár (aki a PPS számmal és a nevével azonosítja magát), a személyi adat nyilvántartó hatóság (MSFA) és az adat-bróker (Public Services Broker). A bróker feladata a gyakran használt személyes adatok nagy biztonságú tárolása (az un. „data vault”-ban), melyeket az ügyfél eseti kérelme esetén, annak mértéke szerint átad a közigazgatási szolgáltatást nyújtó szervnek. A különbözı tranzakciók más-más biztonsági szintő szolgáltatást jelentenek, továbbá folyamatban van a brókernél tárolt adatok titkosításának módszertani kidolgozása. A REACH rendszerre vonatkozó adatvédelmi jogszabályok által elıírt adatvédelmi irányelvek az alábbiak.
szükséges mértékő és törvényes adatkezelés
meghatározott és törvényes célhoz kötés 8

Személyazonosítás az elektronikus közigazgatási szolgáltatások terén – nemzetközi kitekintés, International Business Machines Corporation Magyarország Kft. Informatikai és Hírközlési Minizstérium megbízásából, 2004. október 18., www.itktb.hu/resource.aspx?resourceid=docstorefile&f=701&t=stored

20

Írország







a cél eléréséhez adekvát és releváns adatok kezelése idıben rendszeresen frissített és pontos adatok tárolás a szükséges idıtartamnál tovább nem tárolt a visszaélések és adatvesztés elleni megfelelı adatbiztonság megteremtése.

Az ír adatvédelmi törvény 2002-es módosítása az uniós direktíva elıírásait ültette a jogrendbe. A direktíva alapján megjelenı „hozzájárulás” (adatkezeléshez történı hozzájárulás) fogalma az alábbi: ”az érintett kívánságának önkéntes, kifejezett és tájékozott kinyilvánítása, amellyel beleegyezését adja az ıt érintı személyes adatok feldolgozásához”. A REACH rendszer az adatvédelem magasabb szintjét képes biztosítani, mint a korábbi közigazgatás-közigazgatás modell. Az 1998-as SWA elıírja, hogy


minden tranzakció során, a központi adatbankon (broker/data vault) keresztül kell lekérni az érintett adatait,




pontosan definiálja a „tranzakció” fogalmát,




pontosan meghatározza a bróker használatára köteles szervek listáját.

A REACH különválasztja a személyhez kapcsolódó alapvetı, hosszú távon állandó adatok és az egyes szervek számára szükséges, ill. általuk kezelt és módosított adatok körét. A szétválasztás mellett a fenti adatvédelmi szabályok garantálják a rendszer alkotmányos mőködését:


egy adatot csak egy helyen tárol a rendszer




így az adatok feletti személyes ellenırzés és betekintés lehetısége is egyértelmően biztosított




az adatok javítása egy helyen történik csupán




az alapadatok és szerv-specifikus adatok nem keverednek




a szervek közötti adatcsere pontosan specifikált eljárásban, törvényi garanciák mellett folyik




az adatforgalom törvényességét az SWA és az adatvédelmi törvény szavatolja.

A REACH projekt keretében létrehozott adatbázis az ún. PSI Data Set (Public Service Identity Data Set – PSIDS). PSID tartalmazza az alapadatokat. Az ügyfél kérésére más adatok tárolása is lehetséges, ha azt fel kívánja használni valamely közigazgatási szervvel történı kommunikációban.

3.2.2. A Közigazgatási Szolgáltatás-Bróker (Public Services Broker – PSB) fejlıdése A Reach által létrehozott Public Services Broker (PSB) a belépés helye, amely az ekormányzati infrastruktúra „szolgáltatás orientált architektúrája - SOA” megközelítésén alapuló elektronikus folyamatok, rendszerek, és eljárások integrált együttesébıl épül fel. A Reach ügynökséget az ír kormány bízta meg azzal, hogy fejlesszen ki és vezessen be egy infrastrukturális keretrendszert a közszolgáltatások integrációja és kézbesítése számára Írországban. Az integrációs infrastruktúrát a korábban már emlegetett „Public Services Broker”-nek nevezik (PSB). Az integrációs keret egy szolgáltatás központú architektúrán 21

alapszik, ami egy biztos hardverplatformon fut, és dokumentumokat, standardokat és egy információs portált foglal magába. Az elsıdleges cél az volt, hogy átalakítsák és javítsák a szolgáltatások kézbesítését. A portál 2004 júliusában indult el, míg az integrációs keret 2005ben. Politika kontextus és törvényes keret9 A Strategic Management Initiative (SMI) 1994-ben indult el és nagyon sokféle rendelkezésbıl állt, amitıl azt várták, hogy a közszolgáltatások kézbesítésének a javulását fogja eredményezni. Az 1994-es SMI kezdeményezés vezetett a Delivering Better Government elnevezéső kormányzati jelentéshez. A jelentés ajánlásai között a következıek voltak:
a vevık minıségi információkkal és tanácsokkal történı ellátása,
a szolgáltatások nyújtásának módszereivel kapcsolatban ésszerő választási lehetıségek megadása,
helyi, területi és nemzeti szintő közszolgáltatások integrációja. 1993-ban egy osztályok közötti csoportot állítottak fel, hogy vizsgálja meg és azonosítsa be az integráció észlelt hiányát a szociális intézmények tekintetében Írországban. A csoport jelentését az Integrated Social Services Strategy-t (ISSS) 1996-ban publikálták, melynek fı ajánlásai a következıek voltak:
egyetlen szám használata az ügyfelek számára, mint egyetlen azonosító, a közszolgáltatásokhoz való hozzáférés tekintetében,
az anyakönyvi hivatal (General Register Office) számítógépesítése,
az ügyfelek számára egypontos hozzáférés létrehozása a közszolgáltatások igénybevételére. 1999-ben az ír kormány kiadta az információs társadalomra vonatkozó Kormányzati Cselekvési Tervet (Government Action Plan ont the Information Society). A jelentésben vizsgált területek a következıek voltak: telekommunikációs infrastruktúra, elektronikus kereskedelem és üzleti lehetıségek fejlesztése, törvényhozói rendelkezések, ICT és a közszolgáltatások nyújtása. A Reachet kormányzati döntés alapján 1999-ben hozták létre. 2000 májusában pedig a kormány elrendelte, hogy építse ki a Public Services Brokert.

9

Ireland’s Framework for Transforming Delivery of Public Services, http://www.epractice.eu/cases/ReachPSB

22

Írország

Public Services Broker – PSB mőködése (Verzió 1.0)

2. ábra Forrás: eGovernment, John Purcell, Comptroller and Auditor General, 19 October 2007, http://www.audgen.gov.ie/documents/vfmreports/58_eGovernment.pdf

A PSB elsı verziója szerint a Bróker felhasználói-felület részbıl (Customer Facing Components) és integrációs keretrendszerbıl (Integration Framework) tevıdik össze10. Felhasználói-felület (Customer Facing Components) elemei:


Portál (www.reachservices.ie), amely kb. 1400 kormányzati szolgáltatás listáját és leírását tartalmazza a megfelelı hivatalok és szervek linkjeivel,




„ügyfél – kormányzat” biztonságos belépési pont regisztrált felhasználók számára,




Eset menedzsment komponens, amely biztonsági e-mail „bejövı ablakot” biztosít,




e-Nyomtatvány eszköz,




Biztonsági, ellenırzési és naplózási szolgáltatások,




e-Fizetés – a Bróker rendelkezik egy biztonságos fizetési lehetıséggel (RealX), amely lehetıvé teszi a felhasználók számára, hogy az állami hivataloknak és irodáknak hitelkártyával fizessenek.

10

eGovernment, John Purcell, Comptroller and Auditor General, 19 October 2007, http://www.audgen.gov.ie/documents/vfmreports/58_eGovernment.pdf 23

Integrációs Keretrendszer (Integration Framework):


Alapvetı szolgáltatások (Broker Core Services): o a szolgáltatásokhoz való hozzáférés irányítása a Brókeren keresztül, o adminisztrációs szolgáltatások nyújtása a Bróker számára




Reach Interoperabilitási, Biztonsági és Integrációs Szabványok (Reach Interoperability, Security and Integration Standards - RIGS): útmutatók és szabványok üzenet-átvitelhez. A kormányzat és a magánszektor szolgáltatói számára közzétett anyag, amely részletezi, hogy az üzeneteknek milyen formátumban kell megjelenniük ahhoz, hogy a Brókerrel képesek legyenek kommunikálni. A PSB – más kormányhivatalokkal és szervekkel együttmőködve – megfogalmazta az “Interoperabilitási szabványokat és útmutatásokat”. A következı területeken történt megállapodás11:  Ügyféladatok – adatvédelem, használat, adatgyőjtés és ellenırzés  Biztonsági és belépés-ellenırzési elvek  Ügyfél szolgáltatási elvek és szabványok – beleértve a szolgáltatások továbbítását más ügynökségeknek, szervezeteknek  A Bróker általános szolgáltatásainak használata és a technikai követelmények leírása  A szolgáltatásokra vonatkozó információk szállítása




Szolgáltatás és Adatcsere Katalógus (SDEC – Services Data Exchange Catalogue): tárház vagy tároló terület a RIGS számára.

Tervezett elemek, amik még nem elérhetıek, de a Bróker képes ezeket támogatni, ha igénylik:
Üzleti Szolgáltatások Azonosítója (Business Services Identifier)
Szektorális e-Szolgáltatás Csomópont (Sectoral e-Services Hub)
Ügynökségi e-Szolgáltatás Csomópont (Agency e-Services Hub) Általános Azonosító Rendszer és Interoberabilitási Szabványok: Széles körő Reach interoperabilitási vezérelvek és közös rendszerazonosítók vannak, amelyeket a hivataloknak és ügynökségeknek használniuk kell, ha a Brókerrel akarnak kapcsolatba lépni. Ezeket az SDEC-ben tartják karban. Ebbe beletartoznak azok a vezérelvek és ajánlások, amelyek közös irányelveket és szabványokat fogalmaznak meg a Bróker használatához. Szolgáltatás és Adatcsere Katalógus (SDEC – Services Data Exchange Catalogue): Minden szolgáltatásra, ill. szolgáltatás komponensre vonatkozó információ az SDEC–ben kerül részletezésre. Minden, a PSB-n megjelenı szolgáltatás regisztrálásra és kategorizálásra kerül az SDEC-ben, és kap egy egyedi szolgáltatás-azonosítót, valamint metaadatok kerülnek létrehozásra. 11

Study on Interoperability at Local and Regional Level, Interoperability Study, Final version, Prepared for the eGovernment Unit, DG Information Society and Media European Commission, 20 April 2007, http://ec.europa.eu/idabc/servlets/Doc?id=28787

24

Írország

Ügynökségek közötti Üzenetküldési Szolgáltatás (Inter Agency Messaging Services): Minden a Brókeren keresztül történı kommunikáció XML elektronikus üzenetekkel történik. Az interoperabilitás biztosítására a Bróker szabványos üzenet-szerkezeteket és jelenéseket definiál. A közigazgatásban a számítógépes rendszerek igen nagy variációja található meg. Az interoperabilitás lehetıvé teszi, hogy ezek a különbözı számítógépes rendszerek és hálózatok egymással kommunikálni tudjanak, és együtt tudjanak dolgozni. Jelenleg az ír közszektorban az interoperabilitás terén számos jelentıs fejlesztés és munkafolyamat figyelhetı meg. Az összes állami szerv összekapcsolható a Kormányzati Virtuális Magánhálózat (Government Private Virtual Network) (GVPN) segítségével. A GVPN egyetlen egységes platformot biztosít a szervek számára az internet biztonságos eléréséhez, e-mailek elküldéséhez stb. A Reach kifejlesztette az Inter-Agency Messaging Service (IAMS)-t, megbízható központosított üzenetszolgálatot, amely a GVPN-en bonyolítja az ügyféllel kapcsolatos információk cseréjét a szervek között. Szolgáltatás Orientált Architektúra (Services Oriented Architecture):12 A Bróker egy szolgáltatás-központú architektúrára (SOA) épül. A Public Services Broker (PSB) kiváló gyakorlati megközelítése és megvalósítása a Service Oriented Architecture (SOA)-nak, az EU ajánlásai alapján (Web Services, XML, Üzenetkezelés). A projekt az elektronikus kormányzati infrastruktúrához illeszkedı elektronikus rendszerek, folyamatok, és eljárások integrációját valósítja meg. A mőködés üzeneteken alapul, melyekre garantálják a címzetthez történı biztos eljuttatást, de nem garantálják az azonnali feldolgozást. Az egyes üzeneteket generálhatják személyek, például egy portál felületen keresztül vagy szolgáltatások. Közös jellemzıjük, hogy szabványos, XML formátumban tárolódnak a rendszerben. A közremőködı szolgáltatások megfelelı idıközönként figyelik, hogy van-e számukra feladott üzenet, és szükség szerint kezelik azt. A szolgáltatás-alapú megközelítés megvalósítja a laza csatolást, a helyszín- és protokoll független mőködést. A szolgáltatásokat a rendszerek együttmőködéséhez elegendı szabványos, szabályozott eszközökkel írják le és publikálják, magát a szolgáltatás implementálását az egyes szervezetek saját hatáskörükben tartják. Ez egyben a teljes interoperabilitási rendszer rugalmasságát is adja, hiszen bármely belsı változtatáskor, új rendszerek beüzemelésekor a kapcsolódási felületek változatlanok maradhatnak, csak a szolgáltatás megvalósítási módja változik. Mindez lehetıvé teszi azt, hogy különbözı gyártóktól származó szoftvermegoldások az elvárásoknak megfelelıen kommunikáljanak egymással. Hitelesítési Szolgáltatások (Authentication Services): A Bróker jelenleg 1. szintő azonosítást biztosít az IDMACS nevő komponensén keresztül. A Bróker elküldi az azonosításra alkalmas információkat a Szociális és Egészségügyi Minisztérium PSI rendszerének, ami ellenırzi, hogy az illetı az-e, akinek vallja magát, melynek alapja a név, PPSN, anyja születéskori neve, születési ideje stb.

12

Közigazgatási informatikai rendszerek együttmőködéséhez szükséges adatmodellek és adatkommunikációs sémák specifikációja és az ehhez szükséges módszertan, Tervezet, az Informatikai és Hírközlési Minisztérium megbízásából, 4.2 verzió, IDOM 2000 konzulens Rt., Budapest, 2004. október 26. www.itktb.hu/resource.aspx?ResourceID=_Interoperabilitasi_szabvanyok__projekt_V1 25

Ha az állampolgár átesett az 1. szintő azonosításon, akkor regisztrálva van a Brókernél és saját ügyfél számlája lesz. Az aktiváló kódot a regisztrált címére normál postával küldik el. A helyes felhasználónév és jelszó megadása lehetıvé teszi a regisztrált felhasználók számára a Bróker szolgáltatásainak használatát. Semmilyen további azonosítást, mint pl. aláírás vagy fényképpel való egyezés vizsgálatot nem végez. 2. és 3. szintő azonosítás sokkal több adat ellenırzését igényli a regisztráláskor, amely a személyes találkozástól, szükség esetén a biometrikus adatok felvételéig is terjedhet. Jelenleg a 2. szint kidolgozásán fáradoznak. Biztonsági Keretrendszer és Protokollok (Security Framework and Protocols): A Bróker egy széleskörő biztonsági keretet alkalmaz, amely ipari szabványokra épül, jelesül az ISO 17799-re. Továbbá a biztonság kulcsfontosságú kérdés volt a tervezési folyamatban és a Bróker szerkezetére vonatkozóan több biztonsági követelményt is megfogalmaztak. A jelenlegi technikai szerkezet tartalmazza a megfelelı biztonsági elemeket. Infrastruktúra (Infrastuctura): A hardver infrastruktúra egy gazda-környezetre alapul. eNyomtatvány lehetıségek (eForms Facility): A nyomtatvány lehetıség létezik és hozzáférhetı, de a hivatalok és az ügynökségek nem támogatják ennek használatát. A mai napig egyetlen nyomtatvány (Ombudsmani Hivatal számára) került kifejlesztésre. A Reach egy új architektúrát dolgozott ki, az ügyfelekkel történı online interakciókra a nyomtatványok helyett. eMail: Kifejlesztés alatt áll. Regionális szintő megoldások: A Helyi Kormányzati Számítógépes Szolgáltatások Bizottsága (Local Government Computer Services Board) jó példa azokra a helyi és regionális szintő szereplıkre, amelyek elısegítik az interoperabilitást. Az LGCSB szerepe, hogy az ICT használata vonatkozásában látóteret, tanácsot, iránymutatást és támogatást nyújtson a helyi szerveknek. 2003-ban kísérletbe (POC) kezdtek egy adat interoperabilitási keretrendszerrel (Data Interoperability Framework) (DIF), amelynek során lehetıvé tették, hogy többszörösen eltérı rendszerek saját entitásukat osztott virtuális entitásként képviseljék az összes rendszerben, valamint lehetıvé tették ezeknek az entitásoknak a kétirányú frissítését.13

13

Study on Interoperability at Local and Regional Level, Interoperability Study, Final version, Prepared for the eGovernment Unit, DG Information Society and Media European Commission, 20 April 2007, http://ec.europa.eu/idabc/servlets/Doc?id=28787 26

Írország

Összefoglalva a projekt eredményei:


Ügynökségek közötti Üzenetküldési Szolgáltatás (Inter Agency Messaging Services), amely egy szabvány-alapot kínál, amely egyszerő módját nyújtja a hivatalok és ügynökségek számára, hogy dokumentumokat és adatokat cseréljenek egymással,




Azonosítás és hitelesítés az adófizetésnél,




Interoperabilitási keretrendszer, szabványok és útmutatók formájában, amelyek rendelkezésre állnak minden közszolgáltatást nyújtó szervezet, ügynökség számára saját belsı, ill. külsı rendszerük megalkotása során.

Két jelentıs tervezett funkció 2005 végére nem került átadásra:



Adat integráló tár (Data Vault) Élethelyzet könyvtár - Episode Knowledge Directory (Life Event Directory)

A PSB Architektúra – a PSB különbözı részei hogyan mőködnek együtt

3. ábra Forrás: http://www.epractice.eu/files/upload/gpc/document/74-1181749882.pdf

27

A PSB portál és az Integration Framework – a különbözı részek együttmőködése

4. ábra Forrás: http://www.epractice.eu/files/upload/gpc/document/74-1181749882.pdf

28

Írország

3.3. Reach Interoperabilitási Ajánlások14 A következıkben a „Reach Interoperability Guidlines (RIGs)” azaz az ír interoperabilitási keretrendszer alapdokumentumát mutatjuk be, melynek felépítése a következı: Bevezetés Kontextus Célkitőzés Hatókör Célközönség A dokumentum státusza Áttekintés Interoperabilitási alapelvek Interoperabilitási keretrendszer Transport RIG-ek Alapelvek Transzport Adapterek Bizalmas hosztok Hálózati összekapcsolhatóság Üzenetközvetítı RIG-ek Alapelvek rig100 Egyidejőség Összekapcsolási minták Üzenet közvetítı minták A szolgáltatás jellemzık minısége Mit fog a PSB tenni minden üzenettel Szolgáltatás definíciós RIG-ek Alapelvek Szolgáltatás interfész profilok Szolgáltatás együttmőködési minták Web szolgáltatások Adat /Tartalom RIG-ek Alapelvek Üzenet RIG-ek Üzleti RIG-ek Alapelvek XML irányelvek Alapelvek Alapvetı RIG-ek Következtetések Függelék: Bevezetés az XML használatába a PSB-n belül Referenciák

14

Reach Interoperability Guidelines (RIGs), rig0012, Interoperability, Release: 0.6, Reach, 29 May 2006, http://www.epractice.eu/files/upload/gpc/document/74-1181749888.pdf 29

3.3.1 Bevezetés 3.3.1.1 Kontextus Mint ahogy elnevezése is mutatja, a Reach Public Service Broker (PSB), vagyis a Reach Közszolgáltatási Bróker (a továbbiakban Bróker vagy PSB) közvetíti az ügynökségek közötti szolgáltatásokat az ír közigazgatási szektorban. A Reach szerepe az interoperabilitás szakpolitikáiban és szabványaiban és statútumában tükrözıdik: „ A Reach feladata, hogy szabványokat és mőködési szakpolitikákat fejlesszen ki több olyan területen, amelyek a közszolgáltatások elektronikus nyújtására, a Bróker mőködésére és a szolgáltatásnyújtó ügynökségek valamint a Bróker közötti interakciókra vonatkoznak. A szabványok kifejlesztése és egyeztetése a lehetıségek szerint egy konzultációs folyamat eredményként megy végbe. A Reach közzéteszi és implementálja a keletkezı szabványokat és szakpolitikai dokumentumokat. A Reach együttmőködik a szponzoráló intézményekkel a szükséges elsıdleges törvényi háttér kialakításában.” 3.3.1.2 Célkitőzés Ez a készlet a Reach Interoperabilitási Ajánlásainak egyike, amelynek célja az intézmények és szervezetek segítése a PSB megértésében és abban, hogy az miképpen alkalmazható az interoperabilitási követelmények teljesítésében. 3.3.1.3 Hatókör A dokumentum leírja a Reach interoperabilitási koncepcióját azokkal az elvekkel együtt, amelyeken ez a koncepció alapul. Referenciákkal is szolgál részletesebb RIG-ekre vonatkozóan, ahol ez szükséges. 3.3.1.4 Célközönség A dokumentum a PSB-vel dolgozó üzleti, mőszaki valamint architektúra menedzserek számára készült. 3.3.1.5 A dokumentum státusa A dokumentumban közreadott információ a Reach interoperabilitási alapelveinek állapotát közzétételének idejébıl származtatja. Ez egy élı dokumentum, amelyet szükség szerint folyamatosan naprakésszé tesznek a fejlıdı XML technológiák, a PSB lehetıségek és az ügynökségek szolgáltatásai igényei szerint. A Reach nem vállal felelısséget az Ajánlásokban közzétett információ pontosságáért, megfelelı voltáért és teljességéért. 3.3.2 Áttekintés 3.3.2.1 Interoperabilitási alapelvek A PSB nem más, mint egy Szolgáltatás Orientált Architektúrán (SOA) alapuló integrált folyamat, rendszer és procedúra készlet. A SOA elveinek megfelelıen:

30

Írország

•

A szolgáltatások a PSB alap koncepcióját képezik, ahol a szolgáltatáson olyan tetszıleges logikailag összefüggı egységet kell érteni, amely valamilyen üzleti feladatot teljesít.

•

Azt, hogy a szolgáltatások hogyan létesítik üzleti funkcionalitásukat, a felhasználóktól jól definiált nyilvános interfészek rejtik el.

•

A szolgáltatási interfészek között cserélt információt diszkrét, strukturált XML-el leírt üzleti üzenetek tartalmazzák.

•

A szolgáltatások lazán csatoltak.

•

Az üzleti üzenet típusok struktúráját és szemantikáját publikálják és ezek rendelkezésre állnak a vonatkozó szolgáltatások általi újra felhasználásra.

•

A PSB a szolgáltatásokat közös biztonsági és szolgáltatás menedzsment keretekkel biztosítja.

A PSB-t használó szolgáltatások külsı ügynökségek és szervezetek által nyújtottakat is magukban foglalják. Ezen felül a PSB önmagában is tartalmaz jó néhány megosztott szolgáltatást. Ezek a PSB által menedzselt szolgáltatások elsıdlegesen olyan funkcionalitásokat biztosítanak, amelyek a ReachServices Portálon keresztüli emberi interakciókat tartalmaznak. Ezek e-formanyomtatványokat, e-fizetést, ügykezelést, cím érvényesítést és személyazonosítást foglalnak magukban. Az 5. ábra diagramszerően mutatja be a PSB-t használó szolgáltatásokat.

A PSB SOA és a kapcsolódó szolgáltatások

5. ábra

31

3.3.2.2 Interoperabilitási keretrendszer A PSB Interoperabilitási Keretrendszer a következı összetevıket tartalmazza: •

Reach Interoperabilitási Ajánlások (RIG-ek), amelyeket szolgáltatások implementációjánál kell betartani olyanokkal együtt, amelyeket már megvalósítottak, és a felhasználók rendelkezésére állnak.

•

A Szolgáltatási és Adatcsere Katalógus (Services and Data Exchange Catalogue SDEC), amely a RIG-eket tartalmazza és nyilvánosan hozzáférhetı a http://sdec.reach.ie honlapon.

•

A Szolgáltatásnyújtási Életciklus (Service Delivery Lifecycle – SDLC), amely meghatározza a Reach használatának módszertanát a PSB-re csatlakozó szolgáltatások implementációjára vagy használatára vonatkozóan.

A RIG-ek úgy csoportosíthatók, hogy különbözı „rétegeket” képezzenek interoperabilitási keretrendszerben. Alulról felfelé haladva ezek a rétegek a következık:

az

•

Kommunikációs réteg. Ezek az ajánlások azokat az opciókat tartalmazzák, amelyek a PSB-hez való csatlakozást az adat transzport szinten teszik lehetıvé.

•

Üzenetközvetítı réteg. Ezek az ajánlások taglalják az üzenetek, szolgáltatások közötti cseréjének mikéntjét és azt, hogy az üzenet megbízhatóságát, biztonságát, valamint a szolgáltatások más jellemzıit hogyan biztosítják.

•

Adat/Tartalom Réteg. Ezek az ajánlások az üzenetek strukturálásával és azzal foglalkoznak, hogy tartalmuk mit jelent üzletileg értelmezhetı terminológiában kifejezve. Az ajánlások lehetıvé teszik a szolgáltatási határok mögötti üzleti alkalmazásoknak, hogy „ugyanazt a nyelvet beszéljék”.

•

Szolgáltatás Definíciós Réteg. Az ajánlások ebben a rétegben a SOA szolgáltatásait írják le. Ezek tartalmazzák az olyan információkat más rétegekbıl, amelyekre a felhasználóknak minden szolgáltatás használatához szükségük van, például milyen funkcionalitást biztosít a szolgáltatás, milyen bemeneti üzenet típusok fogadhatók el, milyen kimeneti üzenetek generálódnak, milyen üzenet csere profil a támogatott, milyen szolgáltatás minıség biztosított. Az erre a rétegre vonatkozó ilyen ajánlásokat nevezik Szolgáltatás Interfész Profiloknak.

•

Üzleti Réteg. Ennek a rétegnek az ajánlásai a valós világra vonatkozó szcenáriókat és üzleti folyamatokat írnak le, amelyek a szolgáltatási rétegben meghatározott szolgáltatásokat használnak.

Ezeket a rétegeket metszik a RIG-ek szériái, amelyek az alábbiak szerint kategorizálhatók: •

Alapkonfigurációjú RIG-ek. A PSB nyelve az XML. Az alapkonfigurációjú RIG-ek tartalmazzák az általános ajánlásokat az XML használatára vonatkozóan.

•

Egyéb RIG-ek. Ezek a biztonságra, a PSB portálra, valamint az ehhez csatlakozó tartalomra vonatkoznak.

A RIG-ek struktúráját a diagramszerően a 6. ábra szemlélteti.

32

Írország

A RIG struktúra

6. ábra

3.3.3 Transzport RIG-ek 3.3.3.1 Alapelvek A RIG-eket vezérlı elvek ebben a rétegben a következıket tartalmazzák: •

Az intézményeknek és szervezeteknek képesnek kell lenniük annak a technológiának a kiválasztására, amely legjobban megfelel körülményeiknek anélkül, hogy használniuk vagy akár ismerniük kellene más szolgáltatások által használt technológiákat.

•

A PSB-t használó szervezetekre és ügynökségekre vonatkozó kötelezı jelleget és költségeket minimalizálni kell.

•

Az intézmények között az IT felkészültség és a technológiák sokszínősége különbözı.

•

Nincs egy egyedi, stabil, széles körben alkalmazott technológia szabvány.

3.3.3.2 Transzport Adapterek A fentebb ismertetett alapelveknek megfelelıen a PSB többféle típusú csatlakozási opciót támogat, amelyek mindegyike különbözı transzport adapternek felel meg, s amelyeket egy 33

csatlakozó RIG ír le. A jelenleg rendelkezésre álló adapter típusokat a következı kategóriákba lehet sorolni: •

Ipari-szabvány tároló és továbbító üzenetközvetítı technológiákon alapuló adapterek. Ez jelenleg egy Biztalk adaptert (rig 8201) jelent. Ezen kategóriájú adaptert tipikusan olyan intézmények alkalmazzák, amelyek elızetesen beruháztak ilyen technológiákba, hogy belsı integrációs követelményeknek megfeleljenek a PSB interoperabilitás érdekében.

•

XML over HTTP(S) bázisú adapterek (rig8204). Ezek az adapterek nem igénylik az intézményektıl, hogy beruházzanak, tárold és továbbítsd technológiákba.

•

Egy web-böngészı alapú Üzenet Kliensnek nevezett adapter (rig8203). Ez az adapter csak kis volumenő együttmőködésre alkalmas a PSB-vel, és csak üzenet letöltési képességekkel rendelkezik.

Az intézmények kötelesek a PSB-hez való csatlakozásukhoz a regisztrált transzport adapterek közül egy kiválasztottat alkalmazni. 3.3.3.3 Bizalmas hosztok Azt a fizikai eszköz(öke)t, amelyen keresztül a szolgáltatás a PSB-hez csatlakozik „Bizalmas hosztnak” nevezik. A PSB-hez való sikeres csatlakozáshoz a bizalmas hosztnak meg kell felelnie a Reach Kikötéseknek és Feltételeknek, amelyek az alábbiakat tartalmazzák: •

Egy digitális tanúsítványhoz való regisztrálás, amelyet a Reach ad ki abból a célból, hogy a PSB hitelesíthesse a hosztot.

•

Egy IDMACS azonosító nyilvántartáshoz való regisztrálás, amelyet a Reach ad ki. Az IDMACS a PSB Azonosítás Menedzsment és Hozzáférés Ellenırzés Szolgáltatása.

3.3.3.4 Hálózati összekapcsolhatóság A PSB összekapcsolhatóságát a PSB-vel egyrészt a Kormányzati Virtuális Magánhálózat (GVPN) biztosítja az intézmények részére, másrészt az internet a nyilvános szolgáltatók és szervezetek által hosztolt szolgáltatásokhoz. Az intézmények saját felelıssége bizalmas hosztjaik számára a GVPN összekapcsolhatóság biztosítása. 3.3.4 Üzenetközvetítı RIG-ek 3.3.4.1 Alapelvek A RIG-eket vezérlı alapelvek ebben a rétegben az alábbiak:

34

•

A szolgáltatásoknak közös, transzport független mechanizmussal kell rendelkezniük annak közlésére, hogy támogatni tudják a különbözı, az üzleti igényeknek megfelelı üzenet cserélı formátumokat.

•

A szolgáltatások együttmőködésének lazán csatoltnak kell lennie, hogy a mőszaki és ideiglenes szétcsatolás elınyei érvényre juthassanak.

•

A szolgáltatásoknak különbözı minıségő jellemzıkkel kell rendelkezniük az üzenetekhez beleértve a biztonságot és a tranzakciókat.

Írország

•

A PSB irányítási követelményeirıl, beleértve a monitorozást, auditálást és az üzleti tevékenység jelentési feladatait, gondoskodni kell.

•

Egységes, stabil, széles körben alkalmazott technológiai szabvány nem áll rendelkezésre.

3.3.4.2 rig0100 A fentebb leírt alapelveknek megfelelıen egy üzenetközvetítı boríték került meghatározásra a rig0100-ban leírtakkal összhangban. A „Reach envelope”-ot a PSB-t használó összes szolgáltatásnak alkalmaznia kell. Más szavakkal élve, miután elkészült az elküldendı üzleti üzenet, a szolgáltatásoknak az elküldés elıtt be kell csomagolniuk egy Reach borítékba. A boríték specifikálja az üzenet végszállítási címét az útvonalválasztás, a biztonság, az audit és a nyomon követhetıség egyéb paramétereivel együtt. A Reach az ügynökségek rendelkezésére bocsát egy szoftver kódot a Reach boríték kezeléséhez a támogatott transzport adapter típusokkal való használat céljából. Ahogy a boríték közlekedik a szolgáltatások között, be lesz csomagolva egy bármilyen kommunikáció-szintő csomagolásba, amely megfelel az alkalmazott transzport adapternek. A Reach borítékot hasonlónak lehet tekinteni egy kézbesítendı levél fizikai borítékjához, amely közlekedhet úton, vasúton vagy levegıben mielıtt végsı rendeltetését elérné. A Reach boríték ábrázolása a 7. ábrán látható.

7. ábra

35

3.3.4.3 Egyidejőség Mint egy elosztott közeg, a laza csatolás a PSB kulcs aspektusának tekintendı. Mivel az üzenetközvetítés a PSB-n keresztül aszinkron jellegő, nem létezik architektúra-szintő garancia arra, hogy az üzenetre a szolgáltatás egy adott idıkereten belül válaszol. Koncepcionálisan az összes szolgáltatás állapot nélküli, hosszan futó, esemény-vezérelt üzleti folyamatnak tekinthetı. A szolgáltatások válaszideje a Szolgáltatási Szint Egyezmény függvénye, s nem a technológiáé. Amikor csak lehetséges, a folyamatokat az aszinkron együttmőködés elvén kell modellezni. Viszont abban az esetben, amikor szinkron típusú viselkedésre van szükség, ez szinkronaszinkron adapter alkalmazását teszi szükségessé. További információhoz lásd a rig0019-et. 3.3.4.4 Összekapcsolási minták A PSB aszinkron természete azt jelenti, hogy az intézményeknek nem szükséges nagyteljesítményő technológiával rendelkezniük vagy azonos szintő szolgáltatásrendelkezésre állásokat mőködtetni. A PSB képessége, hogy „puffer zóna”-ként mőködjön különösen fontos olyan szolgáltatásoknál, amelyek „flash flood” karakterisztikával rendelkeznek, mint az adó visszatérítések, az éves liszensz alkalmazások, stb. Ehhez a képességhez alapvetı jelentıségő az a koncepció, hogy a szolgáltatások „push”olják az üzeneteket a PSB-be, míg a szolgáltatások proaktívan kinyerik vagy „pull”-olják az üzeneteket a PSB-bıl. További információhoz lásd a rig0019-et. 3.3.4.5 Üzenetközvetítı minták Az összes szolgáltatás a PSB-n keresztül kommunikál ahelyett, hogy egymással közvetlenül tartanák a kapcsolatot. Ez lehetıvé teszi a szolgáltatások számára, hogy egy egyedi interfészt prezentáljanak a PSB számára és üzeneteket cseréljenek a PSB által elérhetı bármely szolgáltatással. Az Üzenet Csere Formátumok definiálása és implementációja szolgáltatásonkénti alapon történik. Jelenleg a PSB által támogatott két elsıdleges üzenet csere minta az egy-utas üzenetközvetítés és a Request/Response. Más minták implementációjára igény szerint kerülhet sor. További információhoz lásd a rig0019-et. 3.3.4.6 A szolgáltatás jellemzık minısége A PSB garanciát fog nyújtani arra, hogy a PSB által megkapott és visszaigazolt üzenet szigorúan csak egyszer kerüljön továbbításra a fogadó szolgáltatás PSB-jének hozzáférési pontjára. „Default” viselkedésként a PSB nem fogja garantálni az üzenetek továbbításának szekvenciáját.

36

Írország

A PSB nem tudja detektálni vagy megakadályozni a szolgáltatásokat abban, hogy duplikált üzeneteket küldjenek. Ez azt eredményezi, hogy minden szolgáltatás nyújtónak képesnek kell lennie a duplikátumok felfedezésére és kezelésére. További információhoz lásd a rig0019-et 3.3.4.7 Mit fog a PSB tenni minden üzenettel A PSB által megkapott minden egyes üzenet továbbítása elıtt egy feldolgozási lépés sorozaton megy keresztül: • Boríték érvényesítés. A PSB a Reach borítékot a rig0019 séma szerint érvényesíti. Az érvénytelen üzeneteket Negatív Elismerés kíséri, és nem kerülnek továbbításra. • Törzsértékelés (Body Validation). A PSB a rig0100 „Üzenet Típus” elemét fogja használni az Üzenet Típusának azonosítására az üzenet törzsében. A törzs értékelését a SDEC-ben publikált ehhez az üzenet típushoz tartozó séma szerint fogja elvégezni. Az érvénytelen üzenetek nem kerülnek továbbításra. • IDMACS Ellenırzés. A PSB vizsgálni fogja az elemeket a rig0100 borítékban, hogy meghatározhassa a hozzáférési szabályoknak való megfelelést. A szabályok magukban foglalják az üzenettovábbító kilétét, az üzenet típusát, az üzenet szerepét és rendeltetési címét. • Reach Profil Megfelelıség. A PSB ellenırizni fogja, hogy az üzenet törzs megfelel-e a Reach XML profilnak. • Átalakítás a Reach Kanonikus Formájára. A minden megkapott üzenetet kanonikus formába konvertálja (további információ a 8. fejezetben). • A Reach boríték kiegészítése útvonalválasztó és nyomkövetı azonosítókkal. • Irányítsd és továbbítsd az üzenetet egy rendeltetési szolgáltatáshoz csatlakozó sorba, ahonnan a szolgáltatáshoz való továbbítása a rendeltetési szolgáltatás által használt transzport adapteren keresztül történik meg. 3.3.5. Szolgáltatás definíciós RIG-ek 3.3.5.1 Alapelvek A SOA egyik legfontosabb alapelve, hogy a szolgáltatásokat technológia agnosztikus üzleti szempontból értelmezhetı terminológiával lehet meghatározni. Ennek a rétegnek ajánlásai ezt az elvet támasztják alá. Ezek informálják a potenciális felhasználókat arról, hogy mi is a szolgáltatás, és hogyan kell használni azokat, beleértve, de nem korlátozódva az alábbiakra: • • • • • •

A szolgáltatás célja és feladata A szolgáltatás azonosítója Milyen bemeneti üzeneteket vár a szolgáltatás Milyen kimenı üzeneteket generál a szolgáltatás Milyen üzenet közvetítési mintát vár a szolgáltatás A szolgáltatás jellemzıinek biztonsági, tranzakciós és egyéb minısége

3.3.5.2 Szolgáltatás interfész profilok Minden PSB-t használó szolgáltatásnak létre kell hoznia egy Szolgáltatási Interfész Profilt (SIP).

37

A SIP egy, a szolgáltatás felhasználója által használható, olvasható dokumentum-formát jelent. Minden egyes SIP-et a Reach RIG-ként publikál a Szolgáltatások és Adatcsere Katalógusban (SDEC). 3.3.5.3 Szolgáltatás együttmőködési minták Széles értelemben két útja létezik a szolgáltatások együttmőködésének a PSB-n keresztül: a) A szolgáltatás információt tartalmazó üzenetet küldhet egy másik szolgáltatásnak, pld. egy Import Értesítést, vagy adó visszatérítést. Úgyszintén mivel a PSB maga is hosztol olyan szolgáltatásokat, mint az intézmények elektronikus formanyomtatványai, az üzenet lehet egy kitöltött forma kimenete. Az ilyen minta a terminológia szerint deklaratívnak tekintendı. b) A szolgáltatás küldhet egy kérdést tartalmazó üzenetet egy másik szolgáltatásnak, pld. „mi a PPS száma ennek a személynek?” vagy „Érvényes ez a hitelkártya?”. Az ilyen minta interrogatívnak tekintendı. Az üzleti követelmények fogják meghatározni minden specifikus esetre a preferált megközelítést. Az interrogatív megközelítés az adat kettızés csökkentésében nyújt alapvetı üzleti elınyöket. Például ha létezik egy információs mester-forrás, az interrogatív megközelítés lehetıvé teszi a szükséges részhalmaz elérését anélkül, hogy külön adattárhoz kellene fordulni. Továbbmenve, ha az információ az üzenet-szolgáltatáson keresztül kerül nyilvánosságra, más hasonló igényő szolgáltatások és intézmények is hozzáférhetnek. 3.3.5.4 Web szolgáltatások Annak ellenére, hogy a Web szolgáltatás és a SOA terminológiáját gyakran szinonimaként használják, nem ugyanazt jelentik. Valójában a Web szolgáltatások egy speciális szabvány készletet határoznak meg, amelyet lehet egy SOA-n belül használni. Annak bemutatása, hogy a releváns WS (Web szolgáltatás) szabványok hogy vethetık össze ezen területen a RIG-ekkel az alábbi táblázatban látható. PSB Transzport szolgáltatás Szolgáltatás leírás

Többszörös (lásd a 3. fejezetet) Szolgáltatás Interfész Protokollok, amelyek emberek által olvasottak IT feldolgozó rendszerben való feldolgozáshoz SDEC webhely a szolgáltatás leírások és csatlakozó sémák letöltéséhez (SIPS)

Szolgáltatás felfedezés

Megbízható üzenetközvetítés címzés

38

rig0100 és

Megfelelı Web szolgáltatás SOAP általában a HTTP(S)-en WSDL-hez illeszkedı XML fájlok, amelyeket programból lehet olvasni a felhasználó IT feldolgozó rendszerével UDDI a szolgáltatási információ központosított tárházához vagy WSMetaadatExchange a szolgáltatásokhoz információ elérésére közvetlenül egy másik szolgáltatástól WS-Címzés WS-Megbízható Üzenetközvetítés WS-Megbízhatóság

Írország

A WS szabványok stabilitásának relatív hiánya a PSB kidolgozásának idején vezetett az ebben a dokumentumban leírt megközelítéshez. A WS szabványok fejlesztése azóta azonban elismert, és várható, hogy ennek megfelelıen a Reach profilírozza és adoptálja a stabil és a PSB interoperabilitási keretrendszer szempontjából hasznos szabványokat.

3.3.6. Adat/Tartalom RIG-ek 3.3.6.1 Alapelvek A RIG-eket vezérlı alapelvek ebben a rétegben az alábbiakat foglalják magukban: •

Alkalmazások és technológiák jönnek és mennek, de az adat folyamatosan él. Amennyire a praktikum lehetıvé teszi, függetlenné kellene tenni az ıt létrehozó alkalmazástól.

•

Ma nem lehet elıre megmondani, hogy a szolgáltatások mit akarnak tenni az információs vagyonnal holnap. Az információnak következésképen addig, amíg praktikus, függetlennek kell lennie bármely feladattól.

•

A szolgáltatásoknak egy közös nyelvre van szükségük, az üzeneteken belüli adat aktuális jelentésének konzisztens megosztott értelmezésére.

•

Az XML a legmegfelelıbb nyelv az üzenetek kifejezésére azon az alapon, hogy ez a modern számítógép rendszerekhez de facto szabvány és „lingua franca”, és kész képességgel rendelkezik PSB-n keresztüli üzleti üzenetek kialakítására.

3.3.6.2 Üzenet RIG-ek A fent leírt alapelveknek megfelelıen: •

A PSB-t használó összes üzenetnek kötelezıen meg kell felelnie azoknak az XML sémáknak, amelyeket a Reach-el egyeztettek, és mint Üzenet típusú RIG-eket a PSB SDEC-en publikáltak.

•

A sématervezésnél kötelezıen figyelembe kell venni a létezı Üzenet típusú RIG-eket, különösen a közös adat típusokat képviselı RIG-ek újra felhasználását, mint a Név és Cím.

•

A séma tervezésének kötelezıen figyelembe kell vennie a Baseline RIG-eket, amelyek leírják a Reach ajánlásokat az XML használat számára.

•

Ahol megfelelı, a Reach az üzenet típusokat nyílt, nyilvános szabványokra alapozza. Például a Név és Cím RIG-ek bázisa az OASISxNL (Naming Language) és az xAL (Addressing Languge).

3.3.7. Üzleti RIG-ek 3.3.7.1 Alapelvek Ahogy minél több szolgáltatás kezdi használni a PSB-t, segítségével összetett szolgáltatások és folyamatok kialakítása várhatóan egyre nagyobb elınyökhöz vezet.

39

Alapelvnek tekinthetı, hogy az ilyen kialakítások önmagukban is szolgáltatásnak tekintendık, megırizve ez által a PSB szolgáltatás-központú, különben alapvetıen „üres” természetét. Bátorítva a már létezı szolgáltatások rekombinációját új üzleti folyamatokba idıvel, a PSB lehetıvé teszi a „rekombinációs növekedést”. Például a születés esemény üzenetek rendelkezésre állása lehetıvé teszi, hogy a születés regisztráció folyamatát kombinálni lehessen a családi pótlék fizetésének folyamatával. A családi pótlék most automatikus kifizetésre kerül a születési bizonyítvány kiadásakor, ezzel feleslegessé téve az évi 30.000 feldolgozandó kérvényt. Az ilyen típusú, az üzleti lehetıségekkel vezérelt interoperabilitási képesség a PSB alapvetı céljának tekinthetı. 3.3.8. XML ajánlások 3.3.8.1 Alapelvek Mint azt már említettük a PSB nyelve az XML. Hasonlóan egyéb, ún. technológiai „szabványokhoz”, az XML-t is különbözı képpen lehet használni és értelmezni, és lehetséges olyan XML üzenetet létrehozni, amely nem interoperabilis. A PSB választott útja az interoperabilitás biztosítására az, hogy a releváns XML szabványok közül definiálja a saját profilját. Ezt a profilt különbözı RIG-ekben, az ún. alapvetı RIG-ekben írja le. 3.3.8.2. Alapvetı RIG-ek rig0002 Reach Profil (Reach Profile): Definiálja a PSB által elfogadott XML profilokat. Fı fókusza az XML syntax, amit a W3C XML 1.0 ajánlás ír le. rig0003 Névterek (Namespaces): Az XML névterek célja, hogy kiküszöböljék a névütközéseket azzal, hogy definiálják azt a teret, amelyen belül az adatelemek neve alkalmazható. rig0004 Séma nyelvezet (Schema Languages): A PSB elsıdleges séma nyelve a W3C XML séma nyelve, annak adatcentrikus üzenetkezelı képességeire (ellentétben más narratív dokumentumokkal) és elterjedt támogatottságára alapozva. Ez a RIG arra vonatkozó ajánlásokat tartalmaz, hogy hogyan kell a sémákat definiálni. rig0005 Kódolás (Encoding): Sok karakter - ami a normális tipografikus határon túl van különbözı számítógépes rendszerek esetén különbözıképpen értelmezett, s ez befolyásolja az interoperabilitást. Ez a RIG leírja a szolgáltatások számára ajánlott karakter-készleteket. rig0006 Verziókezelés (Versioning): A változások elkerülhetetlenek és a versioning különösen fontos lazán csatolt rendszereknél, ahol a szolgáltatások és a formátumok (üzenetek) idıvel fejlıdnek. Ez a RIG leírja a PSB stratégiáját a változások kezelésére, ami lehetıvé teszi az építı (non-disruptive) módon történı fejlıdést, gyakorlatilag egy séma kiterjesztı mechanizmuson keresztül a hozzá kapcsolódó kezelési modellel, amely modellnek a szolgáltatásnak meg kell felelnie.

40

Írország

3.3.9. Következtetések Ez a dokumentum a szolgáltatásokra fókuszál, ami a PSB fı koncepciója. Azonban megjegyeznénk, hogy van két kulcsfontosságú funkcionalitása a PSB-nek, amely az ügynökségek számára interoperabilitási következményekkel bír: •

Azonosítási menedzsment

•

E-Nyomtatványok

3.3.10. Függelék: Bevezetés az XML használatába a PSB-n belül Mivel az XML és a sémák a PSB interoperabilitás alapjai, ezért a következı rövid ismertetıt adjuk megértésük megkönnyítésére. Az XML tag-okat (szavak ’<’és ’>’ közé zárva) használ adatrészek behatárolására, de azok jelentését és az adat interpretálását az azt olvasó alkalmazásra bízza – ezért található a nevében az „extensible” kifejezés. Ez a kiterjeszthetıség egyaránt az erıssége és a gyengesége is. Például az alábbi ábrán látható három különbözı, Widget-re vonatkozó XML üzenet. Mivel az XML lehetıvé teszi a tervezınek minden egyes sor (elem) tetszıleges elnevezését, mindhárom üzenet egyenlıen érvényes és ugyanazt az információt hordozza. Azonban ha az üzenetet olvasó szolgáltatás az elemeket a „Colour”, „Site”, „Quantity” sorrendben várja, úgy nem lesz képes a C üzenet feldolgozására. Ha a „Size”-ot számként várja, akkor nem lesz képes a B üzenet feldolgozására.

XML séma

8. ábra

41

Ami tehát szükséges, annak módja és biztosítása, hogy egy üzenetnek milyen szerkezetőnek kell lennie. Ezt érjük el az üzenet számára XML séma definiálásával. Ha a D sémát alkalmazzuk, a fenti három üzenetünkre láthatjuk, hogy csak az „A” üzenet érvényes, mivel ez elsınek egy „Colour” nevő elemet tartalmaz, amit a „Size” követ, ami egy egész szám, és végül a „Quantity”. Ha minden szolgáltatás ugyanazt a sémát használja, akkor garantáljuk a strukturálisan érvényes üzenetek küldését és fogadását. Tehát az XML sémákat az üzenetek specifikált szerkezetének (syntaxisának) biztosítására használhatjuk. A küldı és a fogadó közötti értelmes kommunikáció megköveteli még a közös értelmezését a használt szavak mögötti jelentéseknek. A PSB feladata a konzisztens szerkezet és jelentések biztosítása. A PSB-ben használt minden üzenettípusra egy üzenettípus RIG definiálva és publikálva van a SDEC-ben. Minden üzenettípus RIG-hez tartozik egy XML séma, aminek meg kell felelni azoknak az alkalmazásoknak, amelyek az adott üzenettípust használják és biztosítaniuk kell a RIG-ben definiált syntaxot is. Az elemek jelentése a Sémában kerül dokumentálásra.

A PSB mint Szolgáltatás Orientált Architektúra

9. ábra Forrás: http://www.epractice.eu/files/upload/gpc/document/74-1181749882.pdf

42

Írország

A PSB Interoperabilitási Keretrendszer és dokumentumok

10. ábra Forrás: http://www.epractice.eu/files/upload/gpc/document/74-1181749882.pdf

43

3.4. A Bróker Architektúra Modell bemutatása15 A következıkben a Bróker Architektúra Modellt (Broker Architectural Model) mutatjuk be, melynek felépítése a következı: Összefoglalás Magyarázatok A Widget Licence Alkalmazás Példa A dokumentumban használt betőszavak Mi a PSB? Architektúra felépítési elvek Általános elvek Integrációs elvek Mőszaki GYIK Architektúra felépítési nézetek Integrációs nézetek Felhasználói felületi nézetek Egyéb nézetek További, fejleszthetı nézetek Referenciák/ajánlott olvasmány

15

Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

44

Írország

3.4.1. Összefoglalás Ennek a dokumentumnak az a célja, hogy a PSB javasolt szerkezetérıl technikai információkat biztosítson. A dokumentum célközönsége azon Ügynökségi IT Menedzserek, akik a PSB alatti rendszer felépítését mélyebben szeretnék megismerni. A dokumentum másodlagos célközönsége a PSB megvalósítására szerzıdni kívánó pályázók. Elvek: Ez a rész meghatározza azokat az elveket, amelyek a PSB felépítését irányítani fogják. Fı alapelvek: •

A biztonság sarkalatos prioritás a PSB számára, majd ezt követi (fontossági sorrendben) a megbízhatóság, az ügyfélbarátság, a skálázhatóság és a rugalmas bıvíthetıség,

•

Minden PSB szolgáltatás egy három részes modell körül kerül kialakításra – felhasználói felület, integráció (különösen az üzenetküldés) és végrehajtás,

•

Minden átvitt üzenet a PSB-n keresztül egy XML struktúrában, a „Reach Envelope”-ban kerül átvitelre,

•

Idı, hely és környezet kapcsán lazán csatolt szolgáltatások.

Mi az a PSB? Ebben a részben körvonalazzuk a PSB szerkezetének legfontosabb építıelemeit és egy alap szerkezeti vázlatot. Szerkezeti nézetek: • Integrációs nézet: körvonalazza, hogy az Integrációs Keretrendszer szolgáltatások hogyan fogják a PSB magját alkotni, • Felhasználó felületi nézet: leírja, hogy hogyan fognak mőködni a PSB a felhasználókkal kapcsolatban lévı nézetei, • Egyéb nézet: leírja az SDEC (Szolgáltatás és Adatcsere Katalógus - Services and Data Exchange Catalogue) fontosságát a PSB mőködésében, • További fejleszthetı nézetek: körvonalaz olyan nézeteket, amelyek késıbbi fázisban fejlesztésre kerülhetnek.

3.4.2. Mi az a PSB? A PSB egy közös elérési pontot biztosít az e-kormányzat, a közös hozzáférési szabványok, eljárások és támogató szolgáltatások számára, a szükséges infrastruktúrával együtt, hogy az eközigazgatási szolgáltatások hozzáférését olyan egyszerővé és olyan biztonságossá tegye, amennyire csak lehet. Az ügyfél interakciók támogatásán felül a PSB egy szabványosított mechanizmust nyújt az ügynökségek közötti együttmőködés támogatására. A PSB nélkül az ügyfeleknek minden egyes kormányhivatal esetén külön-külön regisztrálniuk és igazolniuk kellene magukat és

45

minden egyes hivatal esetében különbözı eljárásokkal, ügykezeléssel és szabályokkal találnák szembe magukat. A PSB-vel regisztrált felhasználók egyszer belépnek a PSB portálra és a már megszokott azonos kezelıfelületen tetszıleges e-közigazgatási szolgáltatást vehetnek igénybe. A PSB egyedi felhasználók számára lehetıvé teszi saját tranzakciók kezelését, de biztosít mechanizmusokat és eljárásokat üzleti vagy egyedi ügyfelek számára, ügynökségek és közvetítık felhatalmazására, hogy számukra tranzakciókat hajtsanak végre. Ez képessé teszi a PSB-t arra, hogy támogassa a különbözı hozzáférési csatornák használatát és lehetıvé teszi az üzleti tranzakciók felhatalmazottak általi kivitelezését. A PSB online szolgáltatásoknak három különálló része van amint azt a 11. ábrán „PSB magas szintő szerkezete”láthatjuk: •

A felhasználói felület (humán facing) egy portál, ami web alapú információkból (html, pdf, etc) és interaktív nyomtatványokból épül fel.

•

Az integrációs rész, technikailag egy EAI integrációs keretrendszer, amely XML, üzenetküldés és web szolgáltatásokra épül.

•

A szolgáltatás-végrehajtó rész, amelyben a PSB-képes webszolgáltatás veszi és nyugtázza a PSB szolgáltatáskérı üzenet vételét és továbbfeldolgozza az ügynökségi rendszerekben.

A PSB szerepe az ügyféllel való interakció során az elektronikus szolgáltatások ügyfél központú részének biztosítása, és annak biztosítása, hogy a hivatalok megkapják az elektronikus szolgáltatás-kérést megbízhatóan és biztonságosan egy elektronikusan feldolgozható formátumban (XML). Azaz a PSB on-line szolgáltatások három részébıl kettıt biztosít: •

Az felhasználói felület rész a megfelelı PSB közös szolgáltatásokon keresztül biztosított és létrehozza a PSB szolgáltatáskérı üzeneteit, amelyeket átad a PSB integrációs keretrendszer számára.

•

Az integrációs rész biztonságosan és megbízhatóan eljuttatja a PSB szolgáltatáskérı üzeneteket a PSB/ügynökség határra.

•

Az ügynökségek biztosítják a szolgáltatás végrehajtási részét a saját szolgáltatásaik számára.

A PSB szerepe az ügynökségek közötti interakcióban az, hogy azt biztosítsa, hogy az ügynökségek információkat és információ kéréseket tudjanak küldeni, ill. fogadni, biztonságosan és megbízhatóan, elektronikus formában (XML). A felhasználói felület része a PSB-nek tulajdonképpen egy ügynökség vagy hivatal, amely más ügynökségekkel vagy hivatalokkal integrálódik az ügyfélszolgáltatás teljesítése érdekében. Az felhasználói felület része a PSB-nek technológiai terminológiával élve a legrövidebb élettartamú. A PSB „jövı biztossá” tétele érdekében a felhasználói felület komponens és az integrációs komponens közötti bármilyen technológiai függıség minimalizálva van a javasolt szerkezeti felépítésben.

46

Írország

3.4.3. Architektúra felépítési elvek 3.4.3.1. Általános alapelvek 1. A feladat-kritikus infrastruktúra elve 2. Szerkezeti prioritás elve A PSB nem csak egy portál és nem is csak egy weboldal. A PSB elsısorban egy integrációs infrastruktúra, amin az ír e-közigazgatás szolgáltatásai szállítódnak. A szerkezeti prioritási alapelvek fontossági sorrendben: • • • • •

Biztonság, Megbízhatóság, Ügyfélbarátság, Skálázhatóság, Új szolgáltatások hozzáadására való képesség.

3. Megbízhatósági elvek A PSB sziklaszilárd, biztonságos, 24/7-ben mőködı elektronikai rendszer. Ezért, ebbıl kifolyólag távol tartja magát a legújabb technológiáktól. Fı szabályként nem használ a saját mag-felépítésében semmi olyan technológiát: • amelynek nincs nagyon nagy felhasználói bázisa, • amit még nem próbálták ki, és amiben még nem bíztak meg, más összevethetı szituációkban valahol máshol. A PSB szerkezetének egy pragmatikus és változó megközelítést kell alkalmaznia az IT „szabványok” tömkelegére. A Reach megvizsgálja a különbözı szabványokat és kijelöli azokat, amelyek a PSB rendszerben használhatóak. 4. Jövıbeli hozzáférési lehetıségek biztosításának elve A PSB felépítésének támogatnia kell a jövıbeli hozzáférési lehetıségek biztosíthatóságát. 5. A szolgáltat-absztrakciós elvek Minden szolgáltatást az alábbi három részes szolgáltatásmodell alapján kell felépíteni: • Felhasználó felület rész (Human facing part) • Integrációs rész • Végrehajtó rész 6. Virtuális ügynökség elve A szolgáltatásoknak, noha ügynökségek biztosítják ıket, nem szabad elektronikus értelemben egy adott ügynökséghez kötıdniük. Szolgáltatások kerülhetnek és kerülnek is át egyik ügynökségtıl a másikhoz. A jövıben lehetnek olyan szolgáltatások, amelyek átléphetik az ügynökségek határait, és amelyeket nem tulajdonol egyetlen ügynökség sem tradicionális érelemben.

47

3.4.3.2. Integrációs elvek 1. Laza kapcsolat elve A PSB magja olyan egyszerő amilyen egyszerő csak lehet. Minden komplexitás, platformfüggıség, nem 24/7 funkcionalitás stb. a PSB legszélére és nem pedig annak magjába kerül. A PSB szélén lévı funkcionalitások laza kapcsolattal mőködnek. A PSB a laza kapcsolást nagyon szigorúan veszi és ezt az egyes elemek közötti együttmőködés aszinkron adatközpontú interfészre való építésével éri el. Nem lehet direkt, pontból pontba integrálódás (szoros kapcsolás) a PSB komponensei között, hacsak nem feltétlenül szükséges. A laza kapcsolás elve szigorúan érvényesül az integrációs rendszerhez kapcsolódó szolgáltatásokra is. Mind a PSB magja mind pedig a PSB-hez kapcsolódó szolgáltatásoknak, ahol csak lehet, „plug-replacable”-nek kell lenniük. 2. Boríték elv A PSB lazán kapcsolt elemi közötti üzenetek mindegyike egy XML struktúrában van, amely struktúrát Reach Boríték-nak (Reach Envelope) nevezünk, amely részletesen specifikálva van az SDEC-ben. 3. Felépítés, mint Szolgáltatási elv 4. Szolgáltatás-fejlıdési elv Az elektronikus formájú technológiák állandó változásban vannak. A PSB laza csatolású szerkezete használható arra, hogy a PSB bármely e-forma megoldástól való függıségét erısen korlátozzuk. 5. Ügyfélközpontú adatátvitel elve 6. Ügynökségi lábnyom elve 7. Adatátvitel elve 8. A tesztelés, monitoring és diagnosztika elve

3.4.4. Architektúra felépítési nézetek 3.4.4.1. Integrációs nézetek 11. ábra: PSB magas szintő szerkezet (PSB High Level Architecture) 12. ábra: Szolgáltatás Orientált Architektúra (Service Oriented Architecture Views) A SOA hatása a PSB kifejlesztésére. 13. ábra: Reach Boríték (Reach Envelope View) A Reach Envelope szerepének kiemelése feldolgozásában.

48

a

PSB

szolgáltatáskérı

üzeneteinek

Írország

14. ábra: Szinkron és aszinkron üzenetküldés (Synchronous and Asynchronous Messaging Views) Hogyan lehet mind szinkron mind pedig aszinkron kérésfeldolgozást elérni a PSB aszinkron üzenet-kezelési képességeinek használatával. 15. ábra: E-közigazgatási integrációs csomópontok (E-Government Integration Hubs View) A PSB együttmőködése más szektor/ügynökségi/kormányzati elosztókkal. 16. ábra: Transzport csatoló (Transport Adapter View) Ügynökségek hogyan csatlakozhatnak a PSB integrációs rendszer üzenetkezelı szolgáltatásaihoz, különbözı technológiák felhasználásával. A PSB nem kényszeríti az ügynökségeket a semmilyen technológiai megoldás alkalmazására. 17. ábra: Üzleti folyamatok felépítése (Business Process Orchestration View) A szolgáltatás-nyújtóknak milyen lehetıségeik vannak a felépítésre egyéb szolgáltatások publikálására a PSB-n. 18. ábra: Adat-interface (Data Interface View) A PSB lazán csatolt szolgáltatás-orientált természetének megtartásához, az interfészek is a lehetı legegyszerőbbre kerülnek megtervezésre, így azok adat-központúak és nem API központúak lesznek. 19. ábra: Beavatkozó Bróker (Interventionist Broker View) A PSB beavatkozhat a szolgáltatás-kérési üzenetek továbbításába. A szolgáltatások soha nem beszélnek egymáshoz közvetlenül a SOA-n. Minden szolgáltatások-közötti kommunikáció a PSB üzenet-elosztó központján keresztül történik. 20. ábra: PSI/BSI és azonosítás (PSI/BSI and Identity View) A PSI (Public Services Identity Service – Közszolgáltatási Azonosítási Szolgáltatás) és a BSI (Business Services Identity Service – Üzleti Szolgáltatás Azonosítási Szolgáltatás) hasznossága a PSB más szolgáltatásai számára és gyönyörően ábrázolja a különbséget a PSI/BSI szolgáltatások és az IDMACS (Identity Management and Access Control System – Azonosítás Menedzsment és Belépéskontroll Rendszer) szolgáltatás között. 21. ábra: Biztonságos levél (Secure Mail View) Hogyan lehet biztonságos levélküldési szolgáltatást létrehozni a PSB üzenet-rendszerével. 22. ábra: Állampolgári szolgáltatás osztályozás (Citizen Service Taxonomy View) Különbözı mechanizmusok bemutatása, amelyek a PSB használói számára rendelkezésre állnak a szolgáltatások használatakor a Szolgáltatás Osztályozás-on keresztül. 23. ábra: Eset Menedzsment (Case Management View) Eset Menedzsment Szolgáltatás mőködésének bemutatása, amely lehetıvé teszi az ügyfelek számára, hogy megállapítsák szolgáltatás-kérésük aktuális helyzetét.

49

3.4.4.2. Felhasználói felületi nézetek 24. ábra: Információs és szolgáltatás portál (Information and Services Portal View) Az indexelı technológia használatával lehetıvé válik, hogy az ügyfelek egy ponton kapjanak információt a szolgáltatásokról, anélkül, hogy az összes információt központilag kellene tárolni. 25. ábra: Ügyfél megközelítéső szolgáltatás-fejlıdés (Customer Facing Service Evolution View) Látható, hogy szerkezetileg hogyan lehetséges egy szolgáltatás igénybevétele a PSB által megbízhatónak tartott tetszıleges mechanizmuson keresztül. Az alapkövetelmény, hogy a mechanizmus képes legyen a megfelelı PSB szolgáltatás-kérési üzenetek felépítésére.

3.4.4.3. Egyéb nézetek 26. ábra: Szolgáltatás és Adatcsere Katalógus (Sevices and Data Exchange Catalogue SDEC View) A SDEC szerepe: az SDEC egy elektronikus katalógus és regiszter a PSB integrációs keretrendszer által használt szabványok és azonosítók számára. Minden szolgáltatásnak van egyedi azonosítója és metaadata. Az SDEC tartalmazza ezeket az információkat.

50

Írország

PSB Magas szintő szerkezet (PSB High Level Architecture)

11. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Szolgáltatás Orientált Szerkezet (Service Oriented Architecture Views)

12. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

Reach Boríték (Reach Envelope View)

13. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Szinkron és aszinkron üzenetküldés (Synchronous and Asynchronous Messaging Views)

14. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

E-közigazgatási integrációs csomópontok (E-Government Integration Hubs View)

15. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Transzport csatoló (Transport Adapter View)

16. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

Üzleti folyamatok felépítése (Business Process Orchestration View)

17. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Adat-interface (Data Interface View)

18. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

Beavatkozó Bróker (Interventionist Broker View)

19. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

PSI/BSI és azonosítás (PSI/BSI and Identity View)

20. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

Biztonságos levél (Secure Mail View)

21. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Állampolgári szolgáltatás osztályozás (Citizen Service Taxonomy View)

22. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

Eset Menedzsment (Case Management View)

23. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Infromációs és szolgáltatás portál (Information and Services Portal View)

24. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

Ügyfél megközelítéső szolgáltatás-fejlıdés (Customer Facing Service Evolution View)

25. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Szolgáltatás és Adatcsere Katalógus (Sevices and Data Exchange Catalogue - SDEC View)

26. ábra, Forrás: Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf

Írország

3.5.Az Ír Közszolgáltatások Metaadat Szabványa Az Ír Közszolgáltatások Metaadat Szabványa (The Irish Public Service Metadata Standard - IPSMS)16 Az Ír Közszolgáltatások Metaadat Szabványát (IPSMS) abból a célból fejlesztették ki, hogy az állampolgároknak segítséget nyújtsanak a közigazgatási információk és szolgáltatások megtalálásában. Mint ilyen, alapvetı építı elemnek tekinthetı a közigazgatási on-line információk és szolgáltatások fejlesztésében és biztosításában. A metaadat szabvány jelentıségét az ír közigazgatási szektor intézményei számára elıször az „Ajánlott Útmutatók a Közszektor Intézményei részére Web Publikációs Riport” mutatta be, amelyet 1999-ben egy Tárcaközi Csoport jegyzett. Az Ajánlás #6.1 pontja (részlet) Ajánlott, hogy minden új dokumentumot „metaadat tag”-okkal kell leírni és lehetıség szerint a már létezı információkat is „tag”-osítani kell. Az Ajánlás #6.2 pontja (részlet) A Csoport által ajánlott metaadat elem szabvány készlet egy széles körben elfogadott szabványon, a Dublin (Ohio) Core Metaadat elem készleten alapszik. A Tárcaközi Csoport jelentése a webes publikációban az „Ír Információs Társadalom Kormányzati Akcióterve” 42. paragrafusának követelményét elégíti ki. Egy Metaadat Munkacsoportot is létrehoztak a metaadat téma kezelésére, amelyet egy Metaadat Projekt Koordinátor kinevezése követett azzal a feladattal, hogy vizsgálja meg az internetes információk katalogizálásának és leírásának kérdéseit, az ír közszolgáltatás vonatkozó igényeit, és ajánljon, dokumentáljon egy szabványt, amely kielégíti ezeket a követelményeket. A folyamat részeként egy véleményeket és kiegészítéseket igénylı konzultációs anyag született. A Metaadat Projekt Koordinátor vizsgálatainak és ajánlásainak, valamint a konzultációs folyamat eredményeként a Metaadat Munkacsoport elfogadott és javasolt egy szabványt, amely az Ír Közszolgáltatások Metaadat Szabványa (IPSMS) néven vált ismertté.

Ezen a területen a legfontosabb kapcsolódó dokumentumok: The Irish Public Service, Metadata Standard Version 1.0, Part 1, Framework, August 2001 http://www.gov.ie/webstandards/metastandards/ipsms_part1.doc The Irish Public Service, Metadata Standard Version 1.1, USER GUIDE, June 2002 http://www.gov.ie/webstandards/metastandards/manual.doc

16

http://www.gov.ie/webstandards/metastandards/index.html

67

4. Hasznosítható tapasztalatok Az ír kormány az uniós államok közül elsıként tett lépéseket a közigazgatási szolgáltatások elektronikus útra terelésében. Az ír reform azonban nem csak a szolgáltatásokhoz történı hozzáférést kívánta megkönnyíteni, hanem a közigazgatáson belüli adatforgalom ésszerőbb, gyorsabb, pontosabb és nem utolsó sorban törvényesebb módját is. Az ír e-Kormányzat egyik nagyszabású projektje a Public Service Broker – PSB (közigazgatási szolgáltatás-bróker) létrehozás és kiépítése volt. A Szociális és Családügyi Minisztériumon belül 1999-ben hozták létre a Reach Ügynökséget, melynek legfıbb feladata az e-kormányzathoz kapcsolódó tevékenységek kidolgozása, végrehajtása lett. Ennek keretében jött létre a közigazgatási szolgáltatás-brókert a „Public Service Broker” intézménye, mely közvetítıi, segítségnyújtó funkciót tölt be. A PSB alapkoncepciója az volt, hogy egy web-alapú rendszert hozzanak létre, amely integrálja mind a helyi, mind a központi közigazgatás szolgáltatásait, mégpedig egy belépésiponton („one-stop”). A Bróker alapkoncepciója szerint a PSB egy felhasználói felületbıl (costumer-facing component) és egy integrációs keretrendszerbıl (integration framework) tevıdik össze. A felhasználói felület a www.Reachservices.ie portál, ahol az állampolgárok elérhetik a különbözı közszolgáltatásokra vonatkozó információkat ill., az azokat nyújtó szervezeteket. Az integrációs keret pedig képes biztonságosan üzeneteket továbbítani az ügyfelek és a háttér hivatalok és szervezetek számítógépes rendszerei között. Ez a rendszer ugyancsak lehetıvé teszi, hogy a különbözı hivatalok és szervezetek levelezzenek egymás közt, az ügynökségek közötti üzenetküldési szolgáltatás (Inter Agency Messaging Services) használatával. A PSB Integrációs Keretrendszer egy Szolgáltatás Orientált Architektúrán alapszik (SOA), az elektronikus kormányzati infrastruktúrához illeszkedı elektronikus rendszerek, folyamatok, és eljárások integrációját valósítja meg. A Bróker jelenleg azonosítási lehetıséget is biztosít az egyéni felhasználók számára. Ezt a Public Service Identity rendszer használatával teszi meg, mely rendszert a Szociális és Családügyi Minisztérium fejlesztett ki a Reach projekttel kapcsolatban. A PSB rendszerét 2005 decemberében sikerült átadni. Az eredeti elképzelésekhez képest ugyan kevesebb valósult meg, de a projekt így is jelentıs eredményeket ért el, melyek az alábbiak:


Ügynökségek közötti Üzenetküldési Szolgáltatás (Inter Agency Messaging Services), amely egy szabvány-alapot kínál, amely egyszerő módját nyújtja a hivatalok és ügynökségek számára, hogy dokumentumokat és adatokat cseréljenek egymással,




Azonosítás és hitelesítés az adófizetésnél, mely szolgáltatás készen áll az egyéb szolgáltatásokra történı kiterjesztésre,




Interoperabilitási keretrendszer, szabványok és útmutatók formájában, amelyek rendelkezésre állnak minden közszolgáltatást nyújtó szervezet, ügynökség számára saját belsı, ill. külsı rendszerük megalkotása során.

2007 márciusában a kormány azzal bízta meg a Reach-et, hogy folytassa a szolgáltatások fejlesztését, és azt a döntést hozta, hogy a Reach ügynökséget felügyelı bizottságot át kell alakítani és mind a Reach, mind pedig a Bróker tevékenységét felül kell vizsgálni. (A legutóbbi idık fejleményéhez hozzátartozik, hogy 2008. április 1-tıl a REACH összes funkciója és kötelezettsége fölött a Pénzügyminisztérium vette át az irányítást.) Ezen

68

Írország

átvizsgálás alapján az alábbi megállapítások tehetık, melyek számunkra is tanulságul szolgálhatnak:17


A projekt megvalósítása sokkal lassabban és több költséggel folyt, mint ahogy azt eredetileg tervezték,




Ugyan a Reach, a Miniszterelnöki Hivatal és a Szociális és Családügyi Minisztérium vezetésében erıs volt az elkötelezettség a projekt iránt, a kormányzati struktúra nem volt megfelelı és az elvárások nem voltak reálisak.




Egyéb lassító tényezık is felmerültek, amelyek részben a projekt innovatív természetére is kihatással voltak. Ezek az alábbiak voltak: o késlekedés a hosszú távú elvárások tisztázásában és az azokban való egyetértésben, o ellentétes felelısségi körök feloldásának szükségessége, o nehézségek a szerzıdésekhez szükséges követelmények definiálásában, o a stratégiai megközelítés megoldása a beszerzéseknél.




A pénzügyi irányítási struktúra és a döntéshozás nem volt következetes. A 2003-ban létrehozott kisebb Board (felügyelı bizottság) azonban javította az irányítást.

A magyar interoperabilitási keretrendszer kialakításakor a következıket érdemes figyelembe venni az ír tapasztalatokból kiindulva:


SOA használata: Az aszinkron, lazán kötött üzenetváltási architektúra használata lehetıvé teszi, az automatizálás különbözı szintjén álló, és különbözı technológiákat használó szervezetek közötti kommunikációt. A SOA alapú rendszer biztosítja azt, hogy az eltérı platformokat használó különbözı szervezetek, minimális strukturális vagy technológiai következménnyel tudjanak részt venni a projekt megvalósításában.




Nagy átalakítások elkerülése: A szolgáltatások egyre növekvı módon történı kiépítése csak fokozatos változtatásokat igényel, nem szükséges a háttér-intézmények nagyobb mértékő átszervezése.




Szabványok újbóli felhasználása: Ahol lehetséges, már meglévı szabványok használata, vagy ha szükséges, meglévı szabványoknak a projektben történı használatára történı egyedivé tétele. Ahol azonban a projekt megkívánja, új szabványokat kell létrehozni és azokat publikálni kell. Ahol lehetséges, a szabványokat valós esetek/példák felhasználásával az igazi felhasználókkal történı konzultációk segítségével célszerő kidolgozni.

17

eGovernment, John Purcell, Comptroller and Auditor General, 19 October 2007, http://www.audgen.gov.ie/documents/vfmreports/58_eGovernment.pdf

69

70

Írország

MELLÉKLETEK

71

72

Írország

1. Melléklet: Az Ír Közszolgáltatások Metaadat Szabványa

The Irish Public Service Metadata Standard, Version 1.1, USER GUIDE, June 200218 Introduction Irish Public Service Metadata Standard What this website does Using the website Status and Version History Overview Background What is metadata? Why use metadata? Deployment Decisions Which information resources? New Resources Existing Resources How much metadata should be created for each resource? The Business Process Roles and Responsibilities Central Support Local Role Who in the organisation will create and maintain the metadata? Metadata Elements Dublin Core Metadata Element Set Irish Public Service Metadata Element Set Title Creator Publisher Description Subject Identifier Date Date Ranges Type Contributor Format Source Language Coverage Rights Relation Qualifiers

18

The Irish Public Service Metadata Standard, Version 1.1, USER GUIDE, June 2002, http://www.gov.ie/webstandards/metastandards/manual.doc 73

Qualifiers Element Refinements Controlling Data (‘Encoding Schemes’) Encoding Syntax HTML XML/RDF Accuracy Storage Within Page Stored Separately Which to use? Tools A simple template Template Search Engines FAQs Glossary Appendix A Sample metadata record in HTML Appendix B XML/RDF

74

Írország

Metadata Elements Irish Public Service Metadata Element Set Elements are categorised as being any one of three types – Mandatory, Conditional or Recommended. Condition Mandatory Conditional Recommended

Definition Element must be present in order for a metadata record to be in compliance with the IPSMS. Mandatory in certain circumstances. Element should be included where its use enhances the discovery process or assists in a determination as to the suitability or accessibility of a resource.

Each metadata record is to include a number of mandatory elements, namely Title, Creator, Publisher, Subject, Date, Type and Identifier. The Type element is mandatory where a resource matches one of a specified limited number of types taken from a controlled list of terms maintained and approved by the lead agency. Recommended elements are used where they facilitate resource discovery, resource selection or indicate accessibility. An organisation may also identify recommended elements as necessary to facilitate its own particular requirements. Elements used without qualifiers are known as ‘simple’ elements. Where qualifiers are used they are known as ‘qualified’ elements. The Date element must be qualified. For a record to be in compliance with the IPSMS the mandatory elements must be present. Element Title

Element Use DC.Title

Creator

DC.Creator

Subject

DC.Subject

Description

DC.Description

Publisher

DC.Publisher

Date Identifier Contributor

DC.Date.created DC.Date.modified DC.Identifier DC.Contributor

Type

DC.Type

Definition Typically, a name given to a resource. An entity primarily responsible for the intellectual content of the resource. The topic(s) of the content of the resource. An account of the content of the resource. An entity responsible for making the resource available. A date associated with an event in the life cycle of the resource. A unique identifier for the resource. An entity responsible for making a significant contribution to the content of the resource but whose contribution is secondary to the entity entered in the Creator element The category of the resource. Typically, this might indicate

Obligation Mandatory Mandatory

Mandatory Recommended Mandatory Mandatory. Mandatory Recommended

Conditional

75

Element

Element Use

Format

DC.Format

Source

DC.Source

Language

DC.Language

Relation Coverage

DC.Relation DC.Coverage

Rights

DC.Rights

Definition whether a resource was a report, a legislative work, a press release or a circular. Selected from a controlled list. The data format of the resource. Typically, Format may include the media-type or dimensions (e.g. size, duration) of the resource. Selected from a controlled list. A reference to a resource from which the present resource is derived The language(s) of the intellectual content of the resource A reference to a related resource The extent or scope of the content of the resource. Typically identifies the spatial or temporal characteristics of the resource, or jurisdiction. Information about rights held in and over a resource. Typically, a copyright notice or terms of use statement.

Obligation

Recommended

Recommended Recommended Recommended Recommended

Recommended

Title Name Definition Purpose Obligation Qualifier Qualifier label Qualifier Definition Qualifier obligation Encoding Scheme Examples

DC.Title Name given to a document or resource by the creator or publisher Allows the searcher to locate a document based on the title of the document or words contained within Mandatory Alternative DC.Title.alternative Any form of the title used as a substitute or alternative to the formal title of the resource. Recommended ------------

<meta name="DC.Title" content="The Housing Market in Ireland: An Economic Evaluation of Trends and Prospects"> <meta name="DC.Title.alternative" contents="Third Bacon Report">

The title entered in the DC.Title element should be the same as the title that appears in the <TITLE> tag in the of the document. It does not have to mirror that included in the body of the document, which may sometimes differ.

76

Írország

Where more than one title exists, best practice is to include the formal title of the document or resource in the DC.Title element, and enter second and subsequent (common, popular or alternate forms of) titles in the qualified DC.Title.alternative element. A translation of a title is considered a form of the title, and consequently, can be input as an alternative title entry. Example: <meta name="DC.Title. " lang="en" content="Charting our Education Future - White Paper on Education: Summary."> <meta name="DC.Title.alternative" lang="ga" content="Cairt don Oideachais sna Blianta Romhainn - An Páipéar Bán Oideachais: Achoimre."> Creator Label Definition Purpose Obligation Qualifier Encoding Scheme Recommendation Examples

DC.Creator Entity primarily responsible for the content of the resource Allows the searcher to locate a document based on the creator(s) of the document Mandatory -------------------

Creators should be listed separately. <meta name="DC.Creator" content="Peter Bacon and Associates"> <meta name="DC.Creator" content="Comhairle">

The DC.Creator element can be repeated. Recommendation Best practice is to enter the creator as the corporate unit within an agency or organisation responsible for the content of the resource, rather than the name of any individual within that agency or organisation An exception to the above recommendation might be where an individual is directly attributed, within the body of the document/resource itself, with responsibility for creating the intellectual content. Where the responsibility cannot be attributed to one specific division or unit, the larger organisation, or sub-section of the organisation, may be more appropriately attributed as the creator. Alternatively, if more than one entity is responsible for the content of the document/resource, repeat the use of the DC.Creator element. Guidance on Name Entries Personal names, where used, should be listed in inverted order (surname first, followed by forename). Example: <meta name="DC.Creator" content="Byrne, Edward"> Use direct entries for corporate names, i.e. do not invert entries.

77

Example: <meta name="DC.Creator" content="Peter Bacon and Associates"> <meta name="DC.Creator" content="Department of Finance"> NOT <meta name="DC.Creator" content="Finance, Department of"> OR <meta name="DC.Creator" content="Finance (Department)"> The creator entry should also indicate, where appropriate, the larger organisation and any division or section of which the creator is a part. The format is as follows; [Top-level organisation name]. [Main sub-section]. [Unit responsible] (Note the period separator and use of space) Examples: <meta name="DC.Creator" content="Department of Health and Children. Corporate Services Division. Freedom of Information Unit"> <meta name="DC.Creator" content="Department of Public Enterprise. Human Resources Unit"> NOT <meta name="DC.Creator" content="Human Resources Unit, Department of Public Enterprise">

Publisher Label Definition Purpose

Obligation Qualifier Encoding Scheme Examples

DC.Publisher Identifies the (corporate) entity responsible for making the resource available in its current form Allows the searcher to locate a document based on the publisher of the document, or to find all resources made available by a particular organisation. Mandatory -------------------

<meta name="DC.Publisher" content="Department of Finance"> <meta name="DC.Publisher" content="Comhairle">

Best practice is to list the name of the organisation that provides access to the resource in its current form, not the name of the person or section, e.g. Department of Finance, Office of the Ombudsman. Though they may be one and the same, the organisation that hosts the document on its web server is not to be mistaken for the publisher.

78

Írország

Description Label Definition Purpose

Obligation Qualifier Encoding Scheme Examples

DC.Description An account of the content of a resource A description can facilitate the searcher in assessing the appropriateness or otherwise of a document. It can also prove a useful source of indexable terms. Recommended -------------------

<meta name="DC.Description" content="Information on how to contact the Department of Health and Children customer call-in centre"> <meta name="DC.Description" content="Guidelines for employers on the management of workplace health and safety, the preparation of safety statements, and the carrying out of risk assessments">

A description may include but is not limited to: an abstract, table of contents or a free-text account (summary) of the content. A description may also be used to indicate the intended audience or purpose of a resource, if appropriate. Descriptive information may be taken from the item itself. If a description cannot be found either in the introductory or front matter, or the first few paragraphs, it needs to be created following an analysis of the content. A description ought to be informative of the content of the document. Normally, a description should be limited to a few brief sentences. The DC.Description element may not be required where the title included in the DC.Title element is adjudged descriptive of the content of the resource. In all other cases, best practice is to include a description so as to facilitate the searcher in assessing a document for relevance.

Subject Label Definition Purpose

Obligation Qualifier Encoding Scheme Examples

DC.Subject The topic(s) of the content of the resource The Subject element is useful for locating material on a particular topic. For example, ‘Find all information about… adult literacy’. It may also help users determine the relevancy or otherwise of a resource. Mandatory -------------------

<meta name="DC.Subject" content="information technology; people with disabilities; internet; assistive technology"> alternatively; <meta name="DC.Subject" content="health and safety"> <meta name="DC.Subject" content="occupational health"> <meta name="DC.Subject" content="safety statements"> <meta name="DC.Subject" content="workplace safety"> 79

The subject or topic matter of a resource (what a resource is about), to be expressed as keywords or phrases. The intent is to capture the concept(s) inherent in a document/resource. Values must be descriptive of the content, ‘the aboutness’, of a document/resource. Subject terms should reflect the specificity of the content being covered. Avoid using terms too general for the material being covered. Concepts or subject matter minor in nature or given only passing reference should not be described in the Subject element. Please note that terms should be input using the semi-colon delimiter, or alternatively using separate DC.Subject tags. Terms assigned should be selected from a controlled vocabulary or thesaurus if available, in order to control the content of the element and help achieve a consistency in the use of terms. Terms input from a controlled vocabulary such as the Public Service Thesaurus (PST) should indicate the scheme in use, as follows; <meta name="DC.Subject" scheme="PST" content="information technology; people with disabilities; internet; assistive technology"> Resource discovery is the primary purpose in the use of the Subject element.

Identifier Name Definition Purpose Obligation Qualifier Encoding Scheme Examples

DC.Identifier A unique identifier for the resource The Identifier element is used to indicate the location (where available) of the document/resource Mandatory -------------------

<meta name="DC.Identifier" content="http://www.basis.ie/sub1/riskasse.htm">

Generally, the URL (Uniform Resource Locator) of the resource. It is used to indicate the resource location and to distinguish resources from one another. This element can also be used for local identifiers (e.g. ID numbers or call numbers) assigned by the Creator of the resource to apply to a particular item.

80

Írország

Date Label (unqualified) DC.Date Under the IPSMS, the date element must be qualified in order to indicate the meaning of the date given. See below for the two qualifiers approved for use in the IPSMS, Version 1.0. Label Definition Purpose

Obligation Encoding Scheme Examples Label Definition Purpose

Obligation Encoding Scheme Examples Label Definition Purpose

Obligation Encoding Scheme Examples

Label Definition Purpose Obligation Encoding Scheme Examples Label Definition Purpose Obligation Encoding Scheme Examples

DC.Date.created The date a resource or document was created in its present form. The created date indicates when a resource was created. It indicates the currency or time relevance of a resource. It allows a search to be restricted to resources created within a particular time span or on a particular date. Mandatory ISO 8601 standard <meta name="DC.Date.created" content="2001-07-14"> DC.Date.modified The date a resource was modified or updated. The modified date indicates when a resource was modified. It indicates the currency or time relevance of a resource. It allows a search to be restricted to resources modified within a particular time span or on a particular date. Mandatory ISO 8601 standard <meta name="DC.Date.modified" content="2001-08-24"> DC.Date.valid Date of validity of a resource The valid date indicates when a resource becomes valid or ceases to be valid. It may be most useful to represent the time period in which a resource is valid by expressing the period as a range of dates. Recommended. ISO 8601 standard [Indicating a tax period in which a resource is applicable]: <meta name="DC.Date.valid" content="2000-04-01/2001-03-31"> DC.Date.issued Formal publication date of a resource The issued date indicates when a resource was formally published in its current form Recommended. ISO 8601 standard <meta name="DC.Date.issued" content="2001-02-09"> DC.Date.available Date resource became available. Recommended. ISO 8601 standard <meta name="DC.Date.available" content="2001-03-19"> 81

Note: The date is to be recorded using the ISO 8601 standard. . This is: yyyy-mm-dd. Recommendation: When the creation date is first being input (i.e. new document), insert the same date as the modified date. Rationale: Until a document sees its first change after its initial creation, its creation date is in reality the last time the document was modified. Consequently its creation and modified dates are one and the same until a change in the document content occurs. The date refers to the resource, not the metadata record itself. A date range for the intellectual content of a resource must be described using the DC.Coverage element. DC.Date qualifiers (created, modified) allow for increased precision. They are intended to enhance discovery, allowing for a search to be refined based on a document’s creation or modification date. If the full date is unknown, month and year (YYYY-MM) or just year (YYYY) may be used. ISO 8601 also allows for the expression of time if required.

Date Ranges A date range may be appropriate where metadata has been assigned at a collection-level, and the resources that make up the collection covered include various creation dates. It may also be appropriate where the period of validity of a resource needs to be expressed. A date range should be expressed making use of a solidus (/) which separates the two dates. ISO 8601 allows the use of the ‘/’ separator. Example: <meta name="DC.Date.created" content="2001-02-06/2001-07-14"> Note: Information seekers and software may have difficulty interpreting other date formats if used. Type Label Definition Purpose

Obligation Qualifiers Encoding Scheme Examples

82

DC.Type The category of a resource. [DC Definition:The nature or genre of the content of the resource.] Allows the information seeker to locate different categories of resource, such as document types. It allows a search to be restricted to resources of a certain kind or different categories of documents/resources. For example, ‘Find all press releases…’ Conditional -----------IPSDT (Irish Public Service Document Type) <meta name="DC.Type" scheme="IPSDT" content="press release"> <meta name="DC.Type" content="memorandum">

Írország

The DC.Type element can be repeated. The IPSDT list currently approves the following document type indicators: legislation policy report form press release speech Note: In order to comply with the IPSMS, Version 1.0, documents matching any one of the six document types listed on the IPSDT list must so indicate the document type in the metadata DC.Type element. Recommendation: It is recommended that where terms are taken from a controlled list (i.e. the IPSDT list), the controlled vocabulary should be indicated using the ‘scheme’ indicator. For example: <meta name="DC.Type" scheme="IPSDT" content="press release"> Note: Indication of these document types where appropriate serves to enable the Publications list accessible from the Irish Government home page. The government search engine will scan sites for these document types and list them on the Government website Publications page. This will allow information seekers to follow recent developments across all government departments at a single location or to be alerted of recently published material such as legislative acts or policy proposals. Absence from the IPSDT list does not preclude the use of document types not so included on the list. A document may qualify as matching more than one document type. An example might be where a green paper constitutes both a policy proposal and reports on the findings of a research study. The method of indicating more than one document type is by repeat use of the metadata ‘type’ element, e.g. <meta name="DC.Type" scheme="IPSDT" content="policy"> <meta name="DC.Type" scheme="IPSDT" content="report">

Clarification of IPSDT Document Types: Legislation – specifically Acts, Bills, Statutory Instruments. Not documents about same. An exception is where a document can be described as a ‘covering’ document (see What is a ‘cover’ HTML page? in the FAQs section).

83

Policy – specifically white papers, green papers, or those documents which are specifically described as policy documents. Not statements of policy – such may constitute press releases or the transcripts of speeches, for example, and be best described as a ‘Press Release’ or a ‘Speech’. An exception might be where a statement of policy is the only record of an official policy proposal or position. Not documents referring to, or discussing, a white paper, green paper, or documents referring to that which is specifically described as a policy document. An exception is where a document can be described as a ‘covering’ document (see What is a ‘cover’ HTML page? in the FAQs section). Report – specifically that which formally represents the findings of an investigation. Not a document referring to, or discussing, a formal report. An exception is where a document can be described as a ‘covering’ document (see What is a ‘cover’ HTML page? in the FAQs section). Includes annual reports. Form – a document requiring data entry. Includes forms made available online for downloading or printing out. These forms are usually available as MS Word documents or PDF files. Also includes HTML forms that request information from a user, information that can then be processed on the client or sent back to a server. Excludes forms used to send feedback to a webmaster. ‘Covering’ documents are included (see What is a ‘cover’ HTML page? in the FAQs section). Press Release – specifically an official statement released to the press. The subject of a press release does not influence the determination of document type, i.e. a press release announcing the publishing of an annual report does not mean that ‘Report’ is to be entered as a document type along with ‘Press Release’. An exception is where a document can be described as a ‘covering’ document (see What is a ‘cover’ HTML page? in the FAQs section). Speech – specifically the transcript or audio recording of an actual speech. Does not include documents containing extracts from speeches or documents summarising or including comments on speeches. An exception is where a document can be described as a ‘covering’ document (see What is a ‘cover’ HTML page? in the FAQs section).

Contributor Label Definition Purpose

Obligation Qualifiers Encoding Scheme Examples

DC.Contributor An entity responsible for making a contribution to the content of the resource. Useful if needed to identify an entity that has played an important but secondary role and where searching on that entity may be useful in discovering the resource. Recommended -----------<meta name="DC.Contributor" content="MacCabe, Fergal">

Used to identify an entity that has played an important but secondary role in creating the content of the resource and is not specified in the Creator element.

84

Írország

Recommendation: Only use if the entity’s contribution is significant and where searching on the entity may be useful in discovering the resource. If more than one entity has contributed to the intellectual content of the document/resource and requires inclusion, repeat the use of the DC.Contributor element. If a (corporate) entity, the entry should indicate, where appropriate, the larger organisation and any division or section of which the creator is a part. The format is as follows; [Top-level organisation name]. [Main sub-section]. [Unit responsible] (Note the period separator and use of space) Examples: <meta name="DC.Contributor" content="Department of Public Enterprise. Human Resources Unit"> NOT <meta name="DC.Contributor" content="Human Resources Unit, Department of Public Enterprise"> Personal names should be listed surname first, followed by forename.

Format Label Definition Purpose

Obligation Qualifiers Encoding Scheme Examples

DC.Format The data format of a resource. [DC Definition: The digital or physical manifestation of a resource. ] The element allows the searcher to decide if a resource is worth accessing or retrieving, based on the ability of their software to cope with the format of the resource. Recommended -----------IMT (Internet Media Types) <meta name="DC.Format" content="text/html"> <meta name="DC.Format" content="application/pdf; 535kb"> <meta name="DC.Format" content="video/quicktime; 4 minutes, 30 seconds">

Typically, Format may include the media-type or dimensions (e.g. size, duration) of the resource. Format may be used to determine the software, hardware or other equipment needed to display or operate the resource. Information concerning the size of a resource may be included. Consumers can then decide if they wish to download the resource, or if they have the capability to do so.

85

In principle, formats can include physical media such as books, serials, or other nonelectronic media. It becomes necessary to indicate data format where, for example, the format requires software other than a web browser (e.g. plug-in), or where download time is lengthy. A typical example would be a pdf document, where a pdf reader is required to access the document.

Recommendation: Recommended best practice is to select a value for the Format element from a controlled vocabulary. The value may be selected from the IMT list of terms.

IMT (Internet Media Type) – list of most commonly used document formats: IMT text/plain text/html text/xml application/rtf application/msword application/pdf video/quicktime video/mpeg

Description Unformatted text HTML document XML document Rich Text Format (RTF) document Microsoft Word document Portable Document Format (PDF) document Quicktime encoded video MPEG encoded video

A complete list of Internet Media Types (IMT) is available at: http://www.isi.edu/in-notes/iana/assignments/media-types/media-types

Source Label Definition Purpose Obligation Qualifiers Encoding Scheme Examples

DC.Source A reference to a resource from which the present resource is derived. This element can be used if the contained information would be useful for discovery of the current resource. Recommended ----------------------<meta name="DC.Source" content="Department of Social, Community and Family Affairs leaflet SW17"> <meta name="DC.Source content="http://www.dscfa.ie/dept/booklets/sw37.htm">

The Source element is not used to indicate from where the resource is available (Identifier), by whom the resource was created (Creator), or who makes the resource available (Publisher). 86

Írország

In indicating the origin of the intellectual content of a resource, this information may help verify and authenticate the content of the current resource. Source vs. Relation To indicate relationships between resources, it is generally recommended to use the Relation element. Source is used, however, where the content is derived from, but does not replace, the content of another document. The web page from which the content is derived should be shown as the "Source" of the present content. Whereas the present document references the source document, there is no requirement for a link from the source document to the present document. The Relation element does not specifically allow for indicating that one resource has been derived from another. It is there to indicate that one resource a) is a version of another, or b) replaces another, or c) requires the availability of another resource, or d) references another resource, or e) is also available in another format.

Language Label Definition Purpose

Obligation Qualifiers Encoding Scheme Examples

DC.Language The language of the content of the resource. Allows a search to be restricted to resources in a particular language. For example, ‘Locate Irish language documents published by the Department of Education. The information seeker can also decide whether a document is worth retrieving or not based on the language of the content. Recommended -----------ISO 639-1 <meta name="DC.Language" content="en"> <meta name="DC.Language" content="ga">

Recommendation: Recommended best practice is to use the two-letter language code taken from the ISO 639-1 standard. For example, 'en' for English, 'ga' for Irish. The full list of ISO 639-1 2-letter language codes is available at; http://www.loc.gov/standards/iso639-2/englangn.html

87

Coverage Label Definition Purpose

Obligation Qualifiers Encoding Scheme Examples

DC.Coverage The extent or scope of the content of the resource. This element allows a search to be restricted to resources about or relevant to a certain place or time. It also allows the information seeker to determine the suitability or otherwise of a particular resource based on, e.g. jurisdictional coverage or time period. Recommended ----------------------[for Eastern Region Health Authority resource] = <meta name="DC.Coverage" content="Dublin, Kildare, Wicklow"> [for Shannon Development]= <meta name="DC.Coverage" content="Shannon Region"> <meta name="DC.Coverage" scheme="ISO 8601" content="2000-0401/2001-03-31"> <meta name="DC.Coverage" content="August, 2000">

Used to define spatial coverage (geographic area, administrative area) or date coverage. Place names, names of administrative areas, or time periods are preferred. Time periods may be indicated by textual representations; however, use of ISO 8601 is recommended. Recommendation: Where resources are targeted at a level below national level, it is recommended that Coverage be used to indicate the jurisdictional area over which an organisation exercises authority and to which the content is relevant. Recommendation: It is recommended that the date coverage be indicated using the ISO 8601 standard. This is: yyyy-mm-dd. A date range should be expressed making use of a solidus (/) which separates the two dates. ISO 8601 allows the use of the ‘/’ separator.

Rights Label Definition Purpose

Obligation

88

DC.Rights Information about rights held in and over the resource. Useful information to display (as part of the results display record) regarding copyright and/or access constraints associated with a resource. Recommended

Írország

Qualifiers Encoding Scheme Examples

----------------------<meta name="DC.Rights" content="© Department of Health and Children 2000"> <meta name="DC.Rights" content="http://oasis.gov.ie/about/copyright.html"> <meta name="DC.Rights" content="Copying permitted providing source is acknowledged">

A copyright statement is indicative of what a rights statement might entail. Recommendation Though not mandatory, if a resource includes a rights statement, it is recommended to indicate same in the DC.Rights element via a textual statement or a URI pointing to such.

Relation Label Definition Purpose

Obligation Qualifiers Qualifier obligation Encoding Scheme Examples

DC.Relation A reference to a related resource. This element should be used if there are significant resources that are related to the current resource, which may be useful for the consumer to also access or retrieve. Recommended See below Optional -----------[Indicating the present resource is also available in pdf format] = <meta name="DC.Relation.hasFormat" content="http://www.oasis.gov.ie/rights/entitlements.pdf"> [indicating Irish language version of http://www.gov.ie/educ/publications/213233a.htm] = <meta name="DC.Relation.hasVersion" content="http://www.gov.ie/educ/publications/216a33a.htm"> [without qualifier] = <meta name="DC.Relation" content="this electronic edition supersedes the hard copy-only second edition, same title, ISBN 0863402017">

The Relation element ought to be provided where necessary for discovery, or if necessary to utilise the resource once identified. The Relation element references a related resource, indicating the type of relationship.

Recommendation: It is recommended that the Relation element be qualified. Alternatively, include a free text entry stipulating the relationship.

89

The Relation element is not to be used for indicating that one resource has been derived from another. The Source element is used where the content is derived from, but does not replace, the content of another document. For web-based resources the content of the element will usually be a URI. If the related resource is a non-electronic resource some other form of identification for the related resource can be used, such as title, ISBN etc.

Qualifiers The qualifiers below are recommended for the Relation element: Name Label

isVersionOf DC.Relation.isVersionOf

Definition

The described resource is a version, edition, or adaptation of the referenced resource. Changes in version imply substantive changes in content rather than differences in format.

Name Label Obligation Definition

hasVersion DC.Relation.hasVersion Recommended The described resource has a version, edition, or adaptation, namely, the referenced resource.

Name Label Obligation Definition

isReplacedBy DC.Relation.isReplacedBy Recommended The described resource is supplanted, displaced, or superceded by the referenced resource.

Name Label Obligation Definition

replaces DC.Relation.replaces Recommended The described resource supplants, displaces, or supersedes the referenced resource.

Name Label Obligation Definition

isRequiredBy DC.Relation.isRequiredBy Recommended The described resource is required by the referenced resource, either physically or logically.

Name Label Obligation Definition

requires DC.Relation.requires Recommended The described resource requires the referenced resource to support its function, delivery, or coherence of content.

90

Írország

Name Label Obligation Definition

isPartOf DC.Relation.isPartOf Recommended The described resource is a physical or logical part of the referenced resource.

Name Label Obligation Definition

hasPart DC.Relation.hasPart Recommended The described resource includes the referenced resource either physically or logically.

Name Label Obligation Definition

isReferencedBy DC.Relation.isReferencedBy Recommended The described resource is referenced, cited, or otherwise pointed to by the referenced resource.

Name Label Obligation Definition

references DC.Relation.references Recommended The described resource references, cites, or otherwise points to the referenced resource.

Name Label Obligation Definition

isFormatOf DC.Relation.isFormatOf Recommended The described resource is the same intellectual content of the referenced resource, but presented in another format..

Name Label Obligation Definition

hasFormat DC.Relation.hasFormat Recommended The described resource is available in another format.

Summary Sheet Column A DC.Relation.isVersionOf DC.Relation.isReplacedBy DC.Relation.isRequiredBy DC.Relation.isPartOf DC.Relation.isReferencedBy DC.Relation.isFormatOf

Column B DC.Relation.hasVersion DC.Relation.replaces DC.Relation.requires DC.Relation.hasPart DC.Relation.references DC.Relation.hasFormat

Note from the summary sheet above that relationships consist of value pairs (e.g. isFormatOf, hasFormat). If a two-way relationship or association is to be stipulated, one record will indicate one side of the value pair (isFormatOf), while the second record will indicate the 91

other side of the value pair (hasFormat). However, the IPSMS does not require all records to have metadata associated with them, but rather that all records are discoverable via the deployment of metadata. Consequently, it may be in order to use one side only of a value pair, as a resource may reference another with no such reference back from the referenced resource. In the event that a one way relationship only is to be indicated, preference should be given to using the qualifiers indicated in Column B above. An example might be an HTML document indicating the availability of a PDF or MS Word version, with no reference back to the HTML document from a second metadata record (since a second does not exist) attached to the PDF or MS Word document. Example: [Included in the metadata record embedded in a HTML version of a document]:

<meta name="DC.Relation.hasFormat" content="http://www.oasis.gov.ie/rights/entitlements.doc"> Such a deployment would be in compliance with the IPSMS as both formats would be discoverable as a result of the metadata record associated with the HTML document.

Qualiffiers Qualifiers are additions and extensions to the metadata elements and give metadata creators the option to refine the meaning or add precision. For example, it may be of benefit to the user to know that a given date refers to when an item was amended as opposed to when it was first made available. It can be useful to know that the date entry is encoded using a particular convention, or that a term has been selected from a particular list of terms (‘controlled vocabulary’). Qualifiers consist of two types – element refinements and encoding schemes. Qualifiers are not mandatory except when using the Date element.

Element Refinements Element refinements allow you to be more precise about what an element means. The IPSMS, Version 1.0, approves the use of a number of qualifiers. These qualifiers are associated with the following elements; Date Title Relation Note: To ensure compliance with the IPSMS, Version 1.0, the Date element must be qualified. The qualifiers approved for use with the date element are; Date.created Date.modified

92

Írország

Qualifiers are categorised as being either of two types - Mandatory, or Recommended. Condition Mandatory Recommended

Definition Qualifier must be used with the appropriate element. Qualifier should be included where its use clarifies the meaning of the value input for the element or assists in a determination as to the suitability or accessibility of a resource.

Qualifying (‘refining’) the Date element helps indicate what precisely the date means. The qualifier for the Title element may be used for any title that is not the main title, or is a variation or translation of the main title. Qualifying the Title element is not a mandatory requirement. Qualifying the Relation element helps indicate what precisely the relationship is between one resource and another. Neither the use of the Relation element or its qualification are mandatory requirements.

Element

Qualifier

Element Use

Description

Obligation

Title

Alternative

DC.Title.alternative

Used where more than one title is identified.

Recommended

Date

Created

DC.Date.created

Date a resource is created.

Mandatory

Modified

DC.Date.modified

Date a resource is modified.

Mandatory

Is Version Of Has Version Is Replaced By Replaces Is Required By Requires Is Part Of Has Part Is Referenced By References Is Format Of Has Format

DC.Relation.isVersionOf DC.Relation.hasVersion DC.Relation.isReplacedBy DC.Relation.replaces DC.Relation.isRequiredBy DC.Relation.requires DC.Relation.isPartOf DC.Relation.hasPart DC.Relation.isReferenced By DC.Relation.references DC.Relation.isFormatOf DC.Relation.hasFormat

Refers to a related resource.

Recommended

Relation

Alternatively, free text entry stipulating relationship if qualifier not used.

93

Controlling data(’Encoding Schemes’) Encoding schemes identify the rules or authoritative lists used to control the content of a given field. They facilitate metadata creators by 1) providing lists of terms from which they can choose the appropriate name or term, or 2) indicating the form of the name, term or entry to use. They help eliminate inconsistency in data entry by reducing the likelihood of variant or incorrect forms of the same name or term being used, and ensure that within and across organisations personnel are using the same name forms and terms. Ensuring such consistency across records improves the chances of the appropriate resources being retrieved as the result of a search. Value encoding schemes are supported directly in HTML <meta> elements, using the attributes scheme and language (lang). An encoding scheme may indicate the standard determining the format by which •

a date is entered (e.g. ISO 8601 stipulating date in format yyyy-mm-dd)

•

language is indicated (e.g. ISO 639-1 stipulating language entry, e.g. ‘en’) Note: The IPSMS approves the ISO 8601 standard for date form entries (yyyy-mm-dd).

The lang attribute is used to specify the language of the content of the metadata element. It is not to be confused with the DC.Language element, which indicates the language of the content of the resource. Use of the lang attribute is not essential to the metadata record. Recommendation: Recommended best practice is to use the two-letter language code taken from the ISO 639-1 standard. For example, 'en' for English, 'ga' for Irish. Recommendation: It is recommended that a controlled vocabulary be used in conjunction with the Subject element. The lead agency maintains such a controlled vocabulary, known as the Public Service Thesaurus ('PST').. Recommendation: It is recommended that a controlled vocabulary be used in conjunction with the Type element. The lead agency maintains such a controlled list, known as the Irish Public Service Document Type list (‘IPSDT’). Note: In order to comply with the IPSMS, Version 1.0, documents matching any one of the six approved document types listed on the IPSDT list must so indicate the document type in the metadata DC.Type element

94

Írország

Currently, there are only six valid entries included in the IPSDT list of document types; legislation policy report form press release speech The government search engine will scan sites for these document types and present them in date order on the Government Home Page. This will allow browsers to follow recent developments across all government departments at a single location or to be alerted of recently published, e.g., Acts or policy proposals. Recommendation: It is recommended that where terms are taken from a controlled list, the controlled vocabulary should be indicated using the ‘scheme’ indicator. Example: <meta name="DC.Subject" scheme="PST" content="information technology; people with disabilities; internet; assistive technology"> <meta name="DC.Type" scheme="IPSDT" content="press release">

Note: Where a scheme or lang is specified, the value must be encoded according to that scheme. Example: <… scheme="IPSDT" content="legislation"> NOT <… scheme="IPSDT" content="statutory instrument">

Note: Agencies or organisations may input values from their own controlled vocabularies if they so desire. The IPSMS does not place restrictions or exclusions on the use of controlled vocabularies. Where agencies or organisations are using controlled vocabularies not explicitly recommended in the IPSMS, they are asked to register the controlled vocabulary with the lead agency. This may help ensure that conflicts do not exist between vocabularies being used.

95

Examples of the use of encoding schemes: 1) Indicating that the entry in the DC.Title field is in English: <meta name="DC.Title" lang="en" content="Guidelines on Preparing Safety Statements and Carrying Out Risk Assessments"> 2) Indicating that the document type entry ‘press release’ is taken from the IPSDT controlled list of terms: <meta name="DC.Type" scheme="IPSDT" content="press release"> 3) Indicating that the date format used (yyyy-mm-dd) conforms to the ISO 8601 standard: <meta name="DC.Date.created" scheme="ISO 8601" content="2000-01-28"> 4) Indicating that the subject terms are taken from the Public Service Thesaurus (PST): <meta name="DC.Subject" scheme="PST" content="information technology; people with disabilities; internet; assistive technology">

Encoding Syntax Syntax is the manner of expressing the metadata. The two means of expressing metadata are HTML and XML/RDF.

HTML HTML is the standard way for embedding metadata, utilising the <META> tag in the of a document. It can be viewed by looking at the document source. The <META> tag has two main attributes: NAME and CONTENT. The values for both attributes are enclosed in straight double quotes. Each metadata element has a prefix indicating the metadata schema from which the element is drawn. DC indicates that the element is drawn from the Dublin Core metadata scheme. A DC metadata entry looks like this; <meta name="DC.Title" content="Title of document"> Element refinements are not supported directly in HTML <meta> elements, so a syntax convention relying on the use of characters within these text strings is used. To accommodate element refinements, dots (.) are used to append qualifiers to DC element names. A qualified element should look like this; <meta name="DC.Date.created" content="2001-08-23">

96

Írország

<meta name="DC.Relation.isVersionOf" 0346289042">

content="hard

copy

6th

edition,

ISBN

HTML 4.0 allows use of two particular attributes of the <meta> elements, scheme and lang (language). These attributes allow you to indicate an encoding scheme or controlled vocabulary where so used. The scheme and lang attributes should be indicated as follows: <meta name="DC.Type" scheme="IPSDT" content="press release"> <meta name="DC.Title.alternative" lang="ga" content="Tuarascáil Choimisinéara Faisnéise 2000">

Bhliantúil

an

Note the use of case in the above examples.

XML/RDF The W3C Resource Description Framework (RDF) is a developing standard for resource description and discovery using XML and offers the promise of reducing syntax problems. RDF has the status of a W3C recommendation it may soon become the syntax of choice for expressing IPSMS metadata. Developments in, and recommendations on, the encoding of metadata using XML/RDF will follow pursuant on developments in the use and application of XML across the public sector. The User Guide website will keep you informed of such developments. [Appendix B: More information about XML/RDF]

97

Szakirodalmi hivatkozások 1. A helyi és regionális szintő interoperabilitás vizsgálata, Interoperabilitási tanulmány, e-kormányzati költségvetési szerv, Információstársadalmi Fıigazgatóság, Európai Bizottság, 2007. április 20. http://www.ekk.gov.hu/ekk/letoltheto/20080107 2. A Magyar Információs Társadalom Stratégia elektronikus aláírás részstratégiája, Informatikai és Hírközlési Minisztérium, 2003. október http://www.emagyarorszag.hu//kepek/upload/2007-06/e_alairas_1006.pdf 3. A Service Oriented Approach to e-Government Architecture, Propylon, 2004, http://www.idealliance.org/papers/dx_xmle04/slides/oreilly.pdf 4. Az infokommunikáció kormányzati irányításának nemzetközi tapasztalatai: intézmények, az államigazgatás kapcsolatai a vállalatokkal és a lakossággal, KOPINT-DATORG Konjunktúra Kutatási Alapítvány, Budapest, 2002. március 28. 5. Az infokommunikáció kormányzati irányításának nemzetközi tapasztalatai, KOPINT-DATORG Rt., Készült a Miniszterelnöki Hivatal megbízásából, Budapest, 2000. április 6. Broker Architectural Model, Reach, http://www.epractice.eu/files/upload/gpc/document/74-1181749852.pdf 7. Country Report 2007, IRELAND, International Council for Information, Technology in Government Administration, http://www.icait.org/conf41/docs/Conf41_country_report_Ireland.pdf 8. Delivering Better Government, May 1996, http://www.bettergov.ie/attached_files/upload/publications/PDF/DeliveringBetterGov ernment.pdf 9. E-Government Architecture in Ireland, An introduction to the service-oriented approach of the Public Services Broker, Sean McGarth, Fergal Murray, 2004 http://www.idealliance.org/proceedings/xml04/papers/26/paper.pdf 10. eGovernment, John Purcell, Comptroller and Auditor General, 19 October 2007, http://www.audgen.gov.ie/documents/vfmreports/58_eGovernment.pdf 11. e-Közigazgatás 2010 Programterv, Miniszterelnöki Hivatal, 2007 12. Good Practice Case, e-Enabled Child Benefit, Service in Ireland, Case Study, European Commisiion, 30 September 2005, http://unpan1.un.org/intradoc/groups/public/documents/UNPAN/UNPAN023619.pdf 13. Government Executive Series, Leadership in Customer Service: Delivering on the Promise, Accenture, http://nstore.accenture.com/acn_com/PDF/2007LCSDelivPromiseFinal.pdf

98

Írország

14. Implementing the Information Society in Ireland: An Action Plan, January 1999, http://www.taoiseach.gov.ie/upload/publications/238.pdf 15. INFORMATION SOCIETY WORLD PROGRESS REPORT 2004: A VILÁG ELİREHALADÁSA AZ INFORMÁCIÓS TÁRSADALOM TERÉN 2004-BEN MELLÉKLET, BME-UNESCO Információs Társadalom- és Trendkutató

Központjának (ITTK) kutatócsoportja, Budapest, 2004. október – 2005. március, http://www.informaciostarsadalom.hu/web/docs/WPR_2004_melleklet_v2.pdf 16. Ireland 2004, Key Principles of an Interoperability Architecture, http://www.epractice.eu/files/upload/gpc/document/74-1181749873.pdf 17. Ireland, eGovernment Factsheets, European Communities, February 2008, http://www.epractice.eu/index.php?page=document.factsheets&cntr=12 18. Ireland, TOWARDS AN INTEGRATED PUBLIC SERVICE, OECD, 2008, http://www.bettergov.ie/attached_files/upload/IRELANDTowards%20An%20Integrated%20Public%20Service.pdf 19. Ireland’s Framework for Transforming Delivery of Public Services http://www.epractice.eu/cases/ReachPSB 20. Közigazgatási informatikai rendszerek együttmőködéséhez szükséges adatmodellek és adatkommunikációs sémák specifikációja és az ehhez szükséges módszertan, Tervezet, az Informatikai és Hírközlési Minisztérium megbízásából, 4.2 verzió, IDOM 2000 konzulens Rt., Budapest, 2004. október 26. www.itktb.hu/resource.aspx?ResourceID=_Interoperabilitasi_szabvanyok__projekt_V 1 21. Management Information Framework, Project Plan 2004 – 2006, November 2004, http://www.bettergov.ie/attached_files/upload/publications/RTF/MIF%20Project%20P lan%202004%20-%202006.rtf 22. Management Information Framework, Report of the Working Group on Training to the Project Management Subgroup, June, 2002, http://www.bettergov.ie/attached_files/upload/static/ManagementInformationFramew ork.rtf 23. Modernising Service Delivery, Dr. Joe McDonagh, Trinity College Dublin, First Edition, November 2004, http://www.epractice.eu/files/upload/gpc/document/741181749862.pdf 24. New Connections, Government Action Plan, March 2002, http://www.taoiseach.gov.ie/attached_files/Pdf%20files/NewConnectionsMarch2002. pdf 25. Preliminary Study on Mutual Recognition of eSignatures for eGovernment applications, NATIONAL PROFILE IRELAND, IDABC, April 2007, http://ec.europa.eu/idabc/servlets/Doc?id=30680

99

26. Programme for Government, 2007 – 2012, http://www.taoiseach.gov.ie/attached_files/Pdf%20files/Eng%20Prog%20for%20Gov. pdf 27. PUBLIC SERVICE MANAGEMENT ACT, 1997, http://www.bettergov.ie/attached_files/upload/publications/PublicServiceManagement Act1997.rtf 28. Reach Interoperability Guidelines (RIGs), rig0012, Interoperability, Release: 0.6, Reach, 29 May 2006, http://www.epractice.eu/files/upload/gpc/document/741181749888.pdf 29. Study on Interoperability at Local and Regional Level, Interoperability Study, Final version, Prepared for the eGovernment Unit, DG Information Society and Media European Commission, 20 April 2007, http://ec.europa.eu/idabc/servlets/Doc?id=28787 30. Személyazonosítás az elektronikus közigazgatási szolgáltatások terén – nemzetközi kitekintés, International Business Machines Corporation Magyarország Kft. Informatikai és Hírközlési Minizstérium megbízásából, 2004. október 18., www.itktb.hu/resource.aspx?resourceid=docstorefile&f=701&t=stored 31. The Irish Public Service Metadata Standard, Version 1.0, Part 1, Framework, August 2001, http://www.gov.ie/webstandards/metastandards/ipsms_part1.doc 32. The Irish Public Service Metadata Standard, Version 1.1, USER GUIDE, June 2002, http://www.gov.ie/webstandards/metastandards/manual.doc

Linkek: Reach portál www.reach.ie Miniszterelnöki Hivatal http://www.taoiseach.gov.ie/ Sziociális és Családügyi Minisztérium http://www.welfare.ie/topics/ppsn/ Ír kormányzati Portál http://www.irlgov.ie/ Ír kormányzati címtár http://www.askireland.com/ Pénzügyminisztérium http://www.gov.ie/finance/ Elektronikus közbeszerzési portál http://www.e-tenders.gov.ie/

100

Írország

GRID Certification Authory http://www.cs.tcd.ie/grid-ireland/gi-ca/ Computer systems and information technology in Ireland http://arthur.ohara.net/security_a_2_z.htm Citizen Information ont the Government Portal http://www.oasis.gov.ie/ Business Information ont the Government Portal http://www.basis.ie/ Ír Metaadat Szabványok http://www.gov.ie/webstandards/metastandards/index.html

101

Rövidítésgyőjtemény BASIS

Business Access to State Information and Service

CMOD

Centre for Management Organisation and Development (Vezetési Szervezet és Fejlesztési Központ)

FOI

Freedom of Information Act (Információs Szabadság Törvény)

GVPN

Government Private Virtual Network (Kormányzati Virtuális Magánhálózat)

IADE

Inter Agency Data Exchange (Intézményközi adatkapcsolat)

IAMS

Inter Agency Messaging Services (Ügynökségek Közötti Üzenetküldési Szolgáltatás)

ICT

Information and Communication Technology

IDMACS

Identity Management and Access Control System (Azonosítás Menedzsment és Belépéskontroll Rendszer)

IKT

Infokommunikációs Technológia

IPSMS

Irish Public Service Metadata Standard (Ír Közigazgatási Metaadat Szabvány Rendszer)

ISC

Information Society Commission (Információs Társadalom Bizottság)

ISP

Internet Service Provider

ISPU

Information Society Policy Unit (Információs Társadalom Irányító Egység)

ISSS

Integrated Social Services System

LAGS

Local Government Audit Services (Helyi közigazgatási Auditálási Szolgálat)

LGSCB

Local Government Computer Services Board (Helyi Önkormányzati Számítógép Szolgáltatási Testület)

MIF

Management Information Framework (Információs Keretrendszer)

MSFA

Minister for Social and Family Affairs (Szociális és Családügyi Minisztérium)

NPPPU

National Public Procurement Policy Unit (Nemzeti Közbeszerzési Egység)

OASIS

Online Access to State Information and Services

PAYE

Pay as you earn

PKI

Public Key Infrastructure

PPSN

Personal Public Service Number (Személyi közszolgáltatási szám)

PSB

Public Service Broker (Közigazgatási Szolgáltatás Bróker)

PSC

Public Service Card (Közigazgatási Kártya)

PSI

Public Service Identity

PSIDS

Public Service Identity Data Set

102

Írország

RIGs

Reach Interoperability Guidlines (Interoperabilitási Keretrendszer)

SDEC

Services Data Exchange Catalogue (Szolgáltatás és Adatcsere Katalógus)

SDLC

Service Delivery Lifecycle (Szolgáltatásnyújtási Életciklus)

SMI

Strategic Management Initiative

SOA

Service Orientated Architecture (Szolgáltatás Orientált Architektúra)

SWA

Social Welfare Act

XML

Extensible Markup Language (Kiterjeszthetı Leíró Nyelv)

103

Fogalomtár19 Kifejezés Authentikáció, hitelesítés, azonosítás Authenticate

Bróker (e-Bróker, Közigazgatási Szolgáltatás Bróker) Broker (eBroker, Public Services Broker)

Központi adatbank Data vault Letölthetı formanyomtatványok Downloadable forms e-Bróker eBroker Elektronikus formanyomtatványok, eformanyomtatványok eForms Elektronikus kormányzat, e-Kormányzat eGovernment e-Oktatás e-Learning Elektronikus irattárazás Electronic filing Környezet Environment Elektronikus fizetés, e-Fizetés epayments Elektronikus szolgáltatások, e-szolgáltatások eServices e-Szolgáltatási Központ eservices hub

19

Magyarázat, definíció Folyamat vagy módszer, amely során, vagy amelynek alkalmazásával megbizonyosodhatunk arról, hogy valami valós, hiteles és az, aminek lennie kell. Az adatcsere során a kommunikációban résztvevı felek identitása megállapításának és ellenırzésének folyamata. A Reach által biztosított infrastruktúra, technológia és szoftver csomag kulcsfontosságú eleme. A Bróker célja, hogy széles körben nyújtson közös szolgáltatásokat és a hatékony munkát támogató keretrendszereket a közigazgatási intézmények különbözı osztályai, a kormányügynökségek és a nagyközönség számára lehetıvé téve az elektronikus üzenetváltást és az on-line tranzakciókat. Leegyszerősített analógiát használva, a Bróker hasonlít egy olyan telefonközpontra, amely centralizáltan teremti meg a keretet a telefonhívások végfelhasználói közti megfelelı irányításához. Olyan nagy biztonságú adatbank, amelyben a Bróker kezeli a magánszemélyek és vállalkozások személyes vagy üzleti adatait. Az információkat a Bróker ezen a központi adatbankon keresztül teszi elérhetıvé a különbözı osztályok, ügynökségek számára. Elektronikus formátumú sablonok, amelyekhez a végfelhasználó úgy jut hozzá, hogy kéri a formanyomtatvány saját gépére történı továbbítását. Lásd Bróker

Elektronikus on-line formanyomtatványok Olyan elgondolás, amely szerint az állampolgároknak és vállalkozásoknak szóló kormányzati szolgáltatások, információk és tranzakciók elektronikusan is nyújthatók. A tanulási céllal történı tudásátadás elektronikus módszere. Dokumentumok számítógépes rendszerben történı tárolása Adott légkörben, fizikailag lehatárolható területen jelentkezı adottságok és feltételek. Elektronikus rendszeren keresztül történı fizetés

Elektronikus úton nyújtott szolgáltatások. Központi egység vagy rendszerelem, amely támogatja az elektronikus szolgáltatásokat.

Forrás: eGovernment, John Purcell, Comptroller and Auditor General, 19 October 2007, http://www.audgen.gov.ie/documents/vfmreports/58_eGovernment.pdf

104

Írország

Kifejezés Kormányzás Governance Személyazonosítási modul Identity Management Module (IDMACS) Információs és kommunikációs technológia, Infokommunikációs technológia (IKT) Information and Communication Technology (ICT) Üzenetkezelés Messaging

Interoperabilitás Interoperability

Lézerkártya Laser Cards 1. szintő azonosítás Level 1 authentication 2. és 3. szintő azonosítás Level 2 or 3 authentication Üzenet modell definíciók Message Model Definition (MMDs) Módszertan Methodology

20

Magyarázat, definíció A menedzsment tevékenysége feletti felügyeleti és ellenırzési folyamatok. A Brókernek egy modulja, amely biztosítja a személyazonosság ellenırzését és hitelesítését, pl. ellenırzi azt, hogy az on-line közigazgatási szolgáltatást igénybevevı személy valóban az, akinek mondja magát.

Információmenedzsmenttel és kommunikációval kapcsolatos technológia. Az IKT kifejezést gyakran használják az IT (információtechnológia) kifejezés helyett.

Lehetıvé teszi az érintettek közti üzenetváltást a Reach-en keresztül. Egy rendszer vagy termék együttmőködési képessége más rendszerekkel, termékekkel úgy, hogy az ügyfélnek nem kell semmiféle különleges erıfeszítést tennie ennek érdekében. A digitális televíziózás esetében szükséges az interoperabilitás ahhoz, hogy a videóhoz kapcsolva, a különbözı rendszerelemek képesek legyenek együttmőködni. Együttmőködési képesség, a közszolgáltatások információrendszereinek együttmőködésre és egységes használatra való képessége. Az EU meghatározás szerint 3 szintje van:  a szervezeti interoperabilitás biztosítja a különbözı szervezetek, szervezeti egységek belsı folyamatainak együttmőködését;  a szemantikai interoperabilitás biztosítja, hogy a szervezetek, szervezeti egységek között kicserélendı információról pontosan tudható legyen, hogy milyen kontextusban hogyan kell értelmezni, feldolgozni;  a technikai interoperabilitás biztosítja, hogy az információrendszerek közti együttmáködés technikai értelemben megvalósulhasson.20 Elektronikus kártya, amely biztonságos folyamat során nyújt elektronikus szolgáltatásokat és információkat. Gyakran használják a bankszektorban az ATM-ekhez. A személyazonosság egyszerő hitelesítése. A Szociális és Családügyi Minisztérium adatbázisaiban szereplı információkat vetik össze az ügyfél által biztosított adatokkal (név, személyes közszolgáltatási szám, anyja neve, születési idı, stb.) A személyazonosítás magasabb szintje komplex kritériumrendszeren alapulnak, mint a személyes vagy biometrikus azonosítás. Az üzenetek formátumának és felépítésének szabványos definíciója. Adott tudományterületet vagy tevékenységet szabályozó módszerek, keretrendszerek, elvek és szabályok győjteménye vagy rendszere.

Forrás: e-Közigazgatás 2010 Programterv 105

Kifejezés

Middleware Middleware

„Tárolás és gondolkodás” Park and Ponder Személyazonosító szám Personal identification number (PIN) Személyes közszolgáltatási szám Personal Public Service Number (PPSN)

Portál Portal

Program Programme

Elmélet igazolása Proof of concept

Projekt Project Prototípus Prototype Közszolgáltatási kártya Public Services Card Reach Interoperabilitási Irányelvei Reach Interoperability Guideline (RIGs) Reach szolgáltatási portál Reachservices portal RealX RealX

106

Magyarázat, definíció Mőszaki, számítástechnikai kifejezés, amely több szoftver elemet és alkalmazást összekötni képes számítógépes szoftvert takar. Leggyakrabban komplex, több helyen fellelhetı számítógépes alkalmazások esetén használják. Magában foglalja a web szervereket, alkalmazás szervereket, tartalommenedzsment rendszereket és egyéb hasonló eszközöket, amelyek támogatják az alkalmazásfejlesztést és nyújtást. A funkció lehetıvé teszi a felhasználó számára, hogy idıszakosan elmentse részlegesen kitöltött formanyomtatványát a késıbbi befejezésig. A felhasználó így késıbb is visszatérhet a félig kitöltött nyomtatványhoz és késıbb is véglegesítheti azt. Biztonsági célból használatos egyedi szám.

Magánszemélyeknek kiosztott egyedi azonosító szám Írországban. Kapuként szolgáló weboldal, ami számos olyan szolgáltatást nyújt, mint web-keresési lehetıségek, hírek, ingyenes e-mail lehetıség, vitacsoportok, on-line vásárlási lehetıség referencialista és egyéb szolgáltatások. Az egyik legfrissebb trend azonos feltételeket ajánl alkalmazni az egy iparágon belüli ügyfeleknek szolgáltatásokat kínáló oldalak esetében, ilyen pl. web-alapú bankok portálja, amelyen keresztül az ügyfelek hozzáférnek csekkszámlájukhoz, megtakarítási számlájukhoz és befektetési számlájukhoz. Tervezett és koordinált tevékenység csoportok, eljárások és projektek tömege, amelyek speciális célok és eredmények elérése végett jöttek létre, és irányításukat a célok és eredmények elérése befolyásolja. Adott módszer, ötlet vagy rendszer nem teljes körő megvalósítása a megvalósíthatóság bizonyítása érdekében, amelynek célja, hogy igazolja az elmélet, elgondolás hasznos módon történı alkalmazásának lehetıségét. A proof-of-concept általánosságban egy mérföldkı az össze funkciójában mőködı prototípus elıállításának folyamatában. Tervezett munka vagy tevékenység, melynek végrehajtására konkrét idıintervallumot határoztak meg és speciális cél elérését szolgálja. Általánosságban egy gép vagy rendszer már mőködı, de kísérleti változata, amelyet abból a célból hoztak létre, hogy teszteljék az új designfunkciókat a végsı gép, rendszer meg/kiépítését megelızıen. Állampolgárok számára biztosítandó kártya, amellyel könnyebbé és biztonságosabbá tehetı a kormányzati szolgáltatásokhoz történı hozzáférés. A kormányzati és üzleti szolgáltatásnyújtók számára az üzenettovábbításra kidolgozott iránymutatás és szabványgyőjtemény, amely részletesen leírja azt az üzenetformátumot, amellyel, a Brókerrel kommunikálni lehet. Az on-line kormányzati szolgáltatásokhoz vezetı kapuként mőködı web-oldal. Biztonságos elektronikus fizetési eszköz, amely biztosítja az ügyfelek számára, hogy a közigazgatási intézmények felé pénzbeli kötelezettségeiket teljesítsék.

Írország

Kifejezés

Szolgáltatás Orientált Arhitektúra Servic Orianted Architecture (SOA)

Intelligens kártya Smartcard

Magyarázat, definíció A számítástechnikában a szolgáltatás-orientált architektúra olyan szoftver architekturális elméletet fejez ki, amelyben a szolgáltatások használata a szoftver felhasználók igényei szerint alakul. A SOAkörnyezetben, a hálózati csomópontokban válnak elérhetıvé a hálózat többi tagja által igényelt erıforrások, mint független, a hálózati tagok számára szabványos módon hozzáférhetı szolgáltatások. Leegyszerősített analógiával szemléltetve, a SOA olyan, mint a Legojáték. Van 20 vállalkozás, amely Lego építıelemeket és kiegészítıket gyárt. Bármilyen típusú Lego elemet gyárthatnak, de azoknak illeszkedniük kell más Lego-gyártók termékeihez, és meg kell felelniük azoknak a szabályoknak, amelyek az elemek illeszkedésére vonatkoznak (pl. az egyik elem kis bütykei hogyan kapaszkodnak a másik elem mélyedéseibe). A vállalatok a példában a hálózati csomópontok, a szolgáltatás a Lego-elemek gyártása, és mindez azért mőködik, mert betartják a közös illeszkedési szabályokat, vagyis az architektúrát. A hitelkártyához hasonló mőanyag kártya, de a mőanyag lapocskába egy kis elektronikai áramkört ültetnek, ami tulajdonképpen egy mini számítógép, ami nemcsak tárolja, hanem védi és fel is dolgozza az adatokat. Az intelligens kártyákat általában a digitális aláírásra, a korlátozott körben használható szolgáltatások felhasználóinak azonosítására, vagy üzenetek kódolására és dekódolására használják.

107

108