Metodika integrácie IS VS. Všeobecné informácie

Transcrição

1 Metodika integrácie IS VS Všeobecné informácie

2 Obsah 1 CIELE A VÝCHODISKÁ METODIKY OČAKÁVANIA OD METODIKY...4 CIELE METODIKY...5 VÝCHODISKÁ METODIKY...5 PREDPOKLADY...5 ČO NIE JE PREDMETOM METODIKY INTEGRAČNÉ VZORY (BEST PRACTICES) INTEGRAČNÉ VZORY Z POHĽADU ARCHITEKTÚRY Integrácia vo forme informačného portálu Integrácia cez synchronizáciu dát Integrácia na zdieľané biznis funkcionality Integrácia v zmysle SOA architektúry Integrácia vo forme distribuovaného biznis procesu Integrácia B2B INTEGRAČNÉ VZORY Z POHĽADU IMPLEMENTÁCIE Prenos súborov Zdieľané databázy Volanie vzdialenej procedúry Zasielanie správ VÝBER INTEGRAČNÉHO VZORU A IMPLEMENTÁCIE INTEGRÁCIE Princípy pre výber vzoru integračnej architektúry Faktory pre výber implementácie integrácie VYHODNOTENIE INTEGRAČNÝCH VZOROV VOČI PRINCÍPOM ELEKTRONIZÁCIE VS SR PRINCÍPY INTEGRÁCIE ISVS Princípy integrácie na centrálne komponenty APLIKOVANIE PRINCÍPOV INTEGRÁCIE ISVS VOČI INTEGRAČNÝM SCENÁROM A TECHNICKEJ REALIZÁCIÍ INTEGRÁCIE ZHRNUTIE APLIKÁCIE INTEGRAČNÝCH VZOROV V RÁMCI ELEKTRONIZÁCIE VS SR ŽIVOTNÝ CYKLUS INTEGRAČNÉHO ZÁMERU PROJEKTOVÉ A ORGANIZAČNÉ AKTIVITY INTEGRAČNÉHO ZÁMERU Úloha: Dohoda o integračnom zámere Úloha: Projektové riadenie, eskalácia a manažment rizík, monitorovanie Úloha: Vypracovanie dohody o poskytovaní služieb a manažmentu post-implementačných zmien DEFINOVANIE ROZSAHU INTEGRÁCIE - PROCESNÝ/LOGICKÝ A TECHNICKÝ NÁVRH Úloha: Aktualizácia katalógu poskytovaných služieb Úloha: Identifikácia služieb Metodika integrácie IS VS 2/51

3 4.2.3 Úloha: Špecifikácia služieb Úloha: Integračný technický návrh INFRAŠTRUKTÚRA A IMPLEMENTÁCIA INTEGRAČNÉHO ZÁMERU Úloha: Prepojenie infraštruktúry Úloha: Príprava test plánu, testovacích scenárov a prípadov Úloha: Vývoj komponentov pre integráciu Úloha: Vykonanie integračných testov Úloha: Vykonanie používateľských akceptačných testov Úloha: Zavedenie do prevádzky, monitoring PRÍLOHY MAPOVANIE AKTIVÍT V RÁMCI METODIKY INTEGRÁCIE NA ÚROVNE INTEROPERABILITY KLADENÉ V RÁMCI EIF MAPOVANIE VZOROV VO FORME DÁVKOVÉHO PRENOSU, PUSH, PULL A ONLINE NA VZORY TECHNICKEJ IMPLEMENTÁCIE METODIKY INTEGRÁCIE ZOZNAM PRACOVNÝCH PRODUKTOV METODIKY INTEGRÁCIE REFERENCIE Metodika integrácie IS VS 3/51

4 1 Ciele a východiská metodiky Budovanie egovernmentu v rámci SR je podmienené implementáciou architektúry, ktorá zabezpečuje interoperabilitu jednotlivých komponentov za účelom zvýšenia komfortu koncových používateľov. Z dôvodu rôznych prístupov k implementácii jednotlivých realizátorov projektov egovermentu sa javí ako potrebné mať spoločnú metodiku integrácie, ktorá by ju zastrešila metodicky z viacerých pohľadov ako organizácia, procesy a ľudia. Keďže integrujúce projekty sú často z rôznych rezortov je nevyhnutné, aby boli zodpovednosti pri integrácií jasne rozdelené medzi jednotlivé integrujúce strany. Striktnosť verejného sektora má tendenciu pri metodikách prerásť do formálnych rozmerov, preto je nutné, aby metodika bola podporená samotnou praxou integrácie a obsahovala iba nevyhnutné časti. Časti, ktoré nie sú nevyhnutné na integráciu, ale sú osožné, sú vedené ako odporúčania. Metodika integrácie je rozdelená do nasledujúcich kapitol: Úvodná kapitola (1) popisuje očakávania, ciele a východiská metodiky. Kapitola (2) popisuje používané integračné vzory z pohľadu architektúry a implementácie v rámci podnikových informačných systémov spolu s ich charakteristikou, výhodami a nevýhodami. V kapitole (3) sú jednotlivé integračné vzory zasadené do prostredia egovernmentu SR a samotnej verejnej správy. Z tejto analýzy sú vyvodené odporúčania pre aplikovanie týchto vzorov. Kapitola (4) definuje životný cyklus integrácie alebo integračného zámeru, potrebné vstupy a výstupy (pracovné produkty) jednotlivých úloh a zodpovednosti. Súčasťou metodiky sú odporúčané šablóny pracovných produktov, ktoré sú pre zúčastnené strany integračného zámeru relevantné. 1.1 Očakávania od metodiky Priniesť efektívne možnosti riešení integrácie pre projekty budované v rámci egovernmentu; Ponúknuť efektívne možnosti integrácie existujúcich IS VS v rámci ich koncepcií rozvoja; Zníženie nákladov na prevádzku IS VS; Posúdenie a uplatnenie úspešne budovaných integračných riešení - best practices. Metodika integrácie IS VS 4/51

5 1.2 Ciele metodiky Číslo cieľa Cieľ metodiky Referencia cieľa v metodike 1. Definovať základné časti, typy a architektúru integrácie; 2. Popísať princípy a pravidlá integrácie (best practice) 3. Definovať základné požiadavky integrácie na úrovni: - procesnej (harmonogram, míľniky), - organizačnej (tímy, zodpovednosť, riadenie), - finančnej (kto, čo), -zmluvnej (záväzok a podmienky poskytovania a udržateľnosti vzájomného prepojenia na úrovni SLA). 4. Definovať základné požiadavky integrácie na úrovni: - služieb (procesné modely služieb), 5. Definovať základné požiadavky integrácie na úrovni: - technickej (rozhrania, tech. dokumentácia, komunikačná infraštruktúra), 6. Vymedziť nevyhnutné Vstupy / Výstupy pre integráciu za obe strany, ktoré sa integrujú. 2.1, , 3.1, 3.2, , 4.2.1, 4.2.2, , 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, Zaviesť zodpovednosť za poskytovanie štandardizovaných rozhraní, ktoré musí mať ako súbor poskytovaných služieb popísaný systém, ktorý dáta poskytuje Východiská metodiky Národná koncepcia informatizácie verejnej správy; 2. Výnos o štandardoch č. 312/2010 pre informačné systémy verejnej správy a metodický pokyn k výnosu o štandardoch pre informačné systémy verejnej správy; 3. Skúsenosti z integračných stretnutí projektov centrálny elektronický priečinok a Ústredný Portál Verejnej Správy, UPVS; 4. Skúsenosti z Integračných stretnutí projektov Ministerstva Vnútra SR s projektom Ústredný Portál Verejnej Správy, ktorý realizuje agentúra NASES; Predpoklady Nutné predpoklady pre uskutočnenie integračného zámeru v zmysle predloženej metodiky integrácie: - Identifikované medziprojektové väzby (úroveň projekt-projekt) - Katalóg poskytovaných služieb obsahujúci zoznam dostupných služieb ISVS Metodika integrácie IS VS 5/51

6 1.5 Čo nie je predmetom metodiky Predmetom metodiky nie je: - samotná implementácia metodiky na úrovni programu, resp. projektov; - analýza a návrh riešenia konkrétnych integračných problémov v rámci integrácie OPIS projektov; - dať odporúčania na úrovni zmeny NKIVS, resp. legislatívy; - dať rozhodnutia pri technickej realizácií integrácií jednotlivých projektov (ISVS); - dať šablóny ku konkrétnej integrácií, tzn. poskytované šablóny môžu byť rozširované podľa potreby jednotlivých integrácií. Metodika integrácie IS VS 6/51

7 2 Integračné vzory (Best practices) 2.1 Integračné vzory z pohľadu architektúry Kapitola stručne popisuje nasledovné najviac používané integračné vzory z pohľadu architektúry v rámci podnikových informačných systémov[1], [2], [3], [4]: - Integrácia pomocou informačného portálu; - Integrácia cez synchronizáciu dát; - Integrácia na zdieľané biznis funkcionality; - Integrácia v zmysle SOA Architektúry; - Integrácia vo forme distribuovaného biznis procesu; - Integrácia B2B. Integrácia podnikových systémov je zvyčajne implementovaná uplatnením niekoľkých integračných vzorov. Vhodný integračný vzor je vybraný na základe vyhodnotenia funkcionálnych a nefunkcionálnych požiadaviek, ktoré vychádzajú zo stratégie, princípov, priorít a technologického prostredia podniku. Popis jednotlivých integračných vzorov obsahuje krátky popis vzoru a jeho charakteristické vlastnosti Integrácia vo forme informačného portálu Mnoho používateľov potrebuje dopytovať viaceré aplikácie pre vykonanie jednej špecifickej funkcionálnej požiadavky alebo biznis procesu. V tomto prípade informačný portál agreguje informácie z viacerých zdrojových aplikácií do jednotného zobrazenia a tým pádom odbúrava potrebu prístupu užívateľa na jednotlivé aplikácie samostatne. Jednoduché informačné portály môžu rozdeľovať svoje používateľské rozhranie do viacerých zón / vrstiev / úrovní, pomocou ktorých môžu koncoví používatelia komunikovať s jednotlivými aplikáciami z centralizovaného miesta. Charakteristiky: Obrázok 2-1: Integračný vzor informačný portál Pre uvedený integračný vzor treba vyhodnotiť, či je možné všetky potrebné funkcionality iných aplikácií zavolať z webového rozhrania. Od povahy volaných funkcionalít je následne nutné prehodnotiť prispôsobenie formulárov používateľského rozhrania resp. vloženie používateľského rozhrania z aplikácií poskytujúcich požadované funkcionality do používateľského rozhrania informačného portálu. V prípade uvedeného vzoru je taktiež nutné spracovať procesnú logiku pre chybové hlásenia z jednotlivých zdrojových aplikácií a alternatívne procesné toky v prípade nedostupnosti niektorých zdrojových aplikácií Integrácia cez synchronizáciu dát Mnoho aplikácií potrebuje prístup k rovnakým dátam, pričom vo svojej architektúre majú vlastnú bázu dát so špecifickou štruktúrou pre ich interné potreby. V prípade zmeny v jednej aplikácií je nutné túto zmenu preniesť aj do druhej aplikácie, ktorá potrebuje tieto údaje pre svoje biznis procesy aktuálne. Túto požiadavku je možné zabezpečiť implementáciou integračného vzoru na základe synchronizácie dát. Existuje viacero prístupov pre technickú realizáciu synchronizácie dát. Medzi najpoužívanejšími patria: - proprietárna replikácia dát na úrovni databázovej infraštruktúry; - replikácia zasielaním zmenových správ prostredníctvom MOM (message-oriented middleware); - synchronizácia prostredníctvom zmenových dávok, pričom poskytovateľ zmenovej dávky definuje formu synchronizácie (či je súbor prenesený formou push alebo je nutná implementácia pull modelu); Metodika integrácie IS VS 7/51

8 Charakteristiky: Obrázok 2-2: Integračný vzor synchronizácia dát Pre uvedený integračný vzor je hlavný princíp prístup k rovnakým dátam, pričom sa predpokladá, že môžu nastať inkonzistencie medzi aplikáciami z dôvodu časových intervalov prenosu zmien. V závislosti od statickosti dát je možné vybrať, resp. obmedziť výber prístupov k realizácii samotnej synchronizácie, resp. použiť aj iný integračný vzor. Napríklad v prípade výrazne dynamických dát je lepšie v rámci zdrojovej aplikácie vypublikovať službu v zmysle SOA a dáta požadovať z aplikácie online vždy pri exekúcii inštancie biznis procesu. Na úrovni architektúry je nutné vyhodnotiť aj smer synchronizácie a to, kto je spúšťačom a vlastníkom synchronizačných procesov. V prípade implementácie uvedeného integračného vzoru, sa stráca voľná väzba medzi aplikáciami. Toto má za následok zvýšenú prácnosť v prípade zavedenia zmien alebo upgrade aplikácii v budúcnosti Integrácia na zdieľané biznis funkcionality Rovnako ako mnoho aplikácií ukladá redundantné dáta, taktiež implementuje aj redundantné funkcionality. Ak potrebujú viaceré aplikácie využívať rovnaké funkcionality, je vhodné tieto funkcionality vystaviť ako zdieľané biznis funkcionality, ktoré sú implementované práve raz a dostupné pre ostatné aplikácie ako služby. Zdieľané biznis funkcionality môžu riešiť rovnaké požiadavky ako v prípade synchronizácie dát. Rozhodnutie medzi týmito dvoma vzormi je podmienené viacerými kritériami. Hlavným rozhodovacím kritériom je zodpovednosť za udržiavanie samotných dát. Zabezpečenie konzistentných dát pre čítanie je možné realizovať cez synchronizáciu dát, zmeny a vytváranie dát je odporúčané realizovať prostredníctvom zdieľanej biznis funkcionality. Definícia vzoru sa môže prekrývať s prístupom vytvorenia architektúry v zmysle SOA. Z pohľadu definície je SOA prístup pre budovanie biznis aplikácií, ktoré utilizujú spoločné komponenty za účelom podpory biznis funkcií, pričom zdieľaná biznis funkcionalita je funkcia, ktorá je poskytovaná jedným komponentom a je využívaná jedným alebo viacerými inými komponentmi za účelom dosiahnutia efektívnejšej správy funkcionalít a zníženia nákladov na údržbu. Charakteristiky: Obrázok 2-3: Integračný vzor zdieľané biznis funkcionality Použitie integračného vzoru je hlavne v prípadoch funkcionalít, ktoré sú atomické a často volané z jednotlivých sub-komponentov. Slúži hlavne na odbremenenie záťaže s údržbou funkcionalít ako aj na Metodika integrácie IS VS 8/51

9 úsporu prevádzkových nákladov Integrácia v zmysle SOA architektúry Zdieľané biznis funkcionality sú často označované ako služby. Služba je jednoznačne definovaná funkcionalita, ktorá je všeobecne dostupná a odpovedá na dopyty konzumenta služby. V prípade ak subjekt vyskladá kolekciu poskytovaných služieb, vzniká ďalšia požiadavka na dôležité procesy pre správu týchto služieb. V prvom kroku potrebujú aplikácie určitú formu katalógu služieb, kde bude centralizovaný zoznam všetkých dostupných služieb. V druhom kroku každá služba potrebuje popísať svoje rozhranie tak, aby ostatné aplikácie vedeli vytvoriť komunikačný kontrakt so službou. Tieto dve funkcie: katalóg služieb a vytvorenie komunikačného kontraktu sú kľúčové elementy, ktoré vytvárajú SOA architektúru. SOA architektúra eliminuje hranice medzi integráciou a distribuovanými aplikáciami. Nová aplikácia môže byť v tomto prípade vyvinutá tak, že využíva existujúce vzdialené služby poskytované inými aplikáciami. Z tohto dôvodu volanie takejto služby môžeme považovať za integráciu medzi dvoma a viacerými aplikáciami. Charakteristiky: Obrázok 2-4: Integračný vzor - servisne orientovaná architektúra Hlavným cieľom SOA architektúry je modelovať aplikácie s voľnou väzbou (loose coupling), ktoré medzi sebou komunikujú cez presne špecifikované rozhrania. Každá aplikácia publikuje kolekciu poskytovaných služieb a na základe popisných charakteristík definuje pravidlá pre integráciu. SOA prístup smeruje pohľad na systém ako na kolekciu služieb, ktoré poskytuje konzumentom s jasne špecifikovanými vstupnými a výstupnými parametrami. Tento prístup následne umožňuje využívanie poskytovaných služieb v rámci modelovania komplexných biznis procesov, ktoré môžu byť distribuované cez niekoľko heterogénnych aplikácií Integrácia vo forme distribuovaného biznis procesu Hlavným dôvodom pre integráciu je fakt, že jedna biznis transakcia (proces) môže byť rozčlenená medzi niekoľko aplikácií. Jednotlivé funkcionality potrebné pre podporu biznis procesu môžu byť implementované v rámci iných už existujúcich aplikácií vo forme poskytovanej služby. Čo je ale nutné, je zabezpečenie koordinácie volaní služieb orchestrácia. Z tohto dôvodu je možné pridať komponent, ktorý zabezpečuje modelovanie biznis procesov (BPM platforma) a zabezpečuje korektnú exekúciu poskytovaných služieb zo všetkých aplikácií. Integračný vzor vo veľkej miere umožňuje aj automatizáciu aktivít biznis procesov na základe technickej implementácie biznis logiky priamo do aktivít na BPM platforme. Hranice medzi SOA architektúrou a distribuovanými biznis procesmi môžu byť do značnej miery prekryté. Napr. môžeme všetky biznis funkcionality publikovať ako webové služby a implementovať jednotlivé biznis procesy v rámci aplikácie, tak že budú pristupovať k týmto vzdialeným webovým službám v zmysle SOA architektúry. Metodika integrácie IS VS 9/51

10 Obrázok 2-5: Integračný vzor distribuovaný biznis proces Charakteristiky: Nosným prvkom pre výber uvedeného vzoru je analýza priebehu modelovaného biznis procesu. Uvedený integračný vzor je vhodný, ak niektoré aktivity modelovaného procesu sú závislé od poskytovaných služieb iných aplikácií. V prípade, ak subjekt predpokladá väčšie množstvo vykonávaných biznis procesov cez externé aplikácie, je vhodné do architektúry zapracovať komponenty BPM platformy Integrácia B2B Integrácia B2B zahŕňa prepojenie aplikácií jedného subjektu priamo na aplikácie iného subjektu. Tento vzor je hlavne využívaný v prípade komplexne členených procesov. Napríklad služby voči zákazníkom (CRM) a procesy manažmentu dodávateľského reťazca (SCM). Tento vzor už predpokladá nielen využitie poskytovaných služieb iných aplikácií, ale aj prístup k externým biznis entitám týchto aplikácií. Prístup k týmto entitám je zabezpečený jednotlivými aplikáciami, ktoré vystupujú ako hlavné vstupné body. Je nutné podotknúť, že v tomto prípade je zväčša vystavená iba určitá množina aplikácií a biznis entít integrovaných subjektov. V prípade B2B integrácie treba následne vyhodnotiť aj otázky spojené so zabezpečením, komunikáciou, ako aj legislatívne obmedzenia. Charakteristiky: Obrázok 2-6: Integračný vzor integrácia B2B Integračný scenár sa využíva v prípadoch keď je okrem funkcionalít integrovaných aplikácií nutné spracovávať aj biznisové entity inej aplikácie. 2.2 Integračné vzory z pohľadu implementácie Existuje viac prístupov k technickej implementácii integračného vzoru. Je možné sumarizovať ich do štyroch hlavných kategórií, pričom každá kategória sa môže aplikovať pre špecifické integračné zámery a nie je vylúčený ani mix týchto kategórií [5], [6]. - Prenos súborov - Zdieľané databázy - Volanie vzdialenej procedúry - Zasielane správ Prenos súborov Tento prístup zabezpečuje integráciu aplikácií na základe prenosu súborov. Každá aplikácia vytvorí súbory, ktoré potrebujú ostatné aplikácie využívať. V rámci integračného procesu je nutné zabezpečiť transformačnú logiku do iných dátových formátov. Produkcia súborov je vykonávaná v dopredu Metodika integrácie IS VS 10/51

11 definovaných intervaloch. Obrázok 2-7: Implementácia integrácie prenos súboru Implementácia integrácie na základe prenosu súborov má svoje opodstatnenie hlavne v prípadoch keď je nutné prenášať pomerne statické a/alebo objemné informácie. Uvedená technická implementácia môže byť veľmi efektívna ak sa zabezpečí správna konfigurácia intervalov generovania súborov v závislosti od povahy dát a korektné spracovanie možných chybových hlásení. Výhody a nevýhody implementácie: Oblasť pre zhodnotenie Výhody Nevýhody Definícia formátu Časové hľadisko (kedy vygenerovať, kedy konzumovať) a uskladnenie dát (kde bude súbor umiestnený) Previazanosť aplikácií Správa a vytváranie súboru Včasnosť údajov a prenos súborov Na trhu sú už etablované štandardizované formáty textové súbory, csv., XML, atď. Informácie dostupné centralizovane na jednom mieste pre konzumentov Aplikácie nie sú medzi sebou previazané na technickej úrovni, využívajú iba súbory pre aktualizáciu údajov, ktoré vystupujú ako rozhranie aplikácií. Previazanie je iba v rámci spracovania súboru na integračnom rozhraní, kde je potrebné udržiavať metaúdaje resp. mapovanie dátových štruktúr. Nie sú potrebné žiadne dodatočné nástroje alebo integračné platformy Možné preniesť veľké dávky dát na jeden krát Implementácia dodatočnej procesnej logiky pre transformáciu údajov do požadovanej výstupnej formy a procesná logika na strane konzumenta pre spracovanie tohto výstupu. Vyššia záťaž na strane tvorcu súboru (vytvorenie procesov pre generovanie súborov, riešenie chybových situácií), definícia frekvencie, ktorá vyhovuje všetkým konzumentom súborov. Nutné zabezpečenie oznámenia o dostupnosti nových súborov alebo fixne definovať intervaly dostupnosti nových súborov Ak interné zmeny aplikácie majú vplyv na procesy generovania súboru, je nutné zabezpečiť aby sa dodržala as-is funkcionalita. V prípade ak je nutná zmena aj výstupu, tak oznámenie o modifikácií transformačnej logiky voči konzumentom. Záťaž je prenesená na technický dizajn, kde je nutné zabezpečiť názvovú konvenciu, unikátne názvy súborov, logiku pre výmaz súborov, implementácia pravidiel pre uzamknutie súboru a transportné algoritmy (ak je nutný prenos z jedného servra na iný) Údaje nemusia byť v cieľových aplikáciách aktuálne z dôvodu staticky definovaných intervalov pre generovanie súborov. Môže viesť ku inkonzistencii dát (zmena u poskytovateľa ešte nie je prenesená do systému konzumenta, pričom biznis proces Metodika integrácie IS VS 11/51

12 Oblasť pre zhodnotenie Výhody Nevýhody Bezpečnosť Existujú protokoly pre bezpečný prenos napr. SFTP požadoval informácie pred synchronizáciou) Prenos súborov obchádza aplikačnú logiku a tým pádom aj bezpečnostné pravidlá na úrovni biznis logiky. V prípade prenosu cez FTP protokol je dostupná iba základná autentifikácia Zdieľané databázy Technická implementácia integrácie na základe prenosu súborov zabezpečí prenos údajov medzi aplikáciami, ale v prípade kritickej nutnosti aktuálnosti dát nie je toto riešenie spoľahlivé. Aj keď zvýšime frekvenciu synchronizácie dát, môže nastať inkonzistencia v údajoch z dôvodu oneskoreného importu dát do cieľovej aplikácie. Taktiež integrácia na základe prenosu súborov nemusí dostatočne zabezpečovať kompatibilitu dátových formátov z dôvodu, že zdrojová a cieľová aplikácia môže byť implementovaná na heterogénnych platformách. V prípade keď je nutné zabezpečiť uvedené požiadavky, implementácia integrácie využitím zdieľanej databázy je vhodné riešenie. Obrázok 2-8: Implementácia integrácie zdieľaná databáza Zdieľané databázy sú zamerané na elimináciu odozvy pri spracovaní dát tým, že povoľujú viacerým aplikáciám priamy prístup na jednotné úložisko dát. Taktiež odbúravajú problémy s kompatibilitou dátových typov z dôvodu jednotnej databázovej schémy. Čítanie údajov zo zdieľanej databázy je zvyčajne bezproblémové, ale v prípade vykonania zápisu dát z viacerých zdrojov môže dôjsť k narušeniu údajovej základne. Aj keď mechanizmy transakčnej integrity zamedzujú súbežnú aktualizáciu, nezabezpečia uloženie zlých dát. Výhody a nevýhody implementácie: Oblasť pre zhodnotenie Výhody Nevýhody Včasnosť údajov Všetky aplikácie používajú X rovnaké údaje. Formát dát Otázky ohľadom X transformácie údajov sú eliminované štandardizovanými databázovými typmi DBMS. Návrh a modifikácie zdieľanej databázy X Veľmi komplikovaný návrh jednotnej databázy, ktorý by mal pokryť požiadavky všetkých integrovaných aplikácií. Závažné organizačné komplikácie X Ak by niektoré kritické aplikácie mali znášať spomalenie iba z dôvodu spoločnej databázovej schémy, Metodika integrácie IS VS 12/51

13 Oblasť pre zhodnotenie Výhody Nevýhody bude návrh rozdielnych separátnych databáz nevyhnutný. Dopad na databázovú infraštruktúru X Databázová infraštruktúra je často realizovaná jedným technologickým riešením, ktoré môže spôsobiť vážny vendor lock-in. Frekvencia čítania a modifikácie Bezpečnosť Rýchla odozva z dôvodu priameho prístupu na databázu Je možné zabezpečiť enkryptovanie dát v rámci databázy. Integrované aplikácie využívajúce zdieľané databázy často čítajú a upravujú údaje v databáze. Toto môže spôsobiť úzke miesta prevádzky a taktiež problémy s uzamknutím požadovaných dát medzi jednotlivými aplikáciami v procese modifikácie, tzn. transakčnosť. Dáta môžu byť chránené v zmysle smerníc a pravidiel inštitúcie. Zdieľaním sa môžu sprístupniť údaje, ktoré by niektoré inštitúcie nemali mať dostupné Volanie vzdialenej procedúry Implementácia integrácie na základe prenosu súborov a zdieľaných databáz zabezpečí dostupnosť relevantných dát v aplikáciách. Môžu ale nastať prípady, kedy dáta nestačia a proces v rámci jednej aplikácie potrebuje zavolať funkcionalitu inej aplikácie. V takýchto prípadoch, aplikácia vystupuje ako komponent, ktorý zapúzdruje svoje dáta a voči vonkajšiemu prostrediu publikuje rozhranie, ktoré je možné zavolať a na základe dodaných vstupných parametrov vykoná požadovanú funkcionalitu. Existuje viacero technológií pre implementáciu volania vzdialenej procedúry napríklad Java RMI,.NET Remoting, COBRA, COM. Obrázok 2-9: Implementácia integrácie volanie vzdialenej procedúry V prípade tohto prístupu je každá aplikácia vyvinutá ako komponent so zapúzdrenými dátami. Každý komponent poskytuje rozhranie voči ostatým aplikáciám, na základe ktorého môžu aplikácie komunikovať a zabezpečiť splnenie požiadaviek na funkcionalitu. Napriek tomu, že zapúzdrenie pomáha znížiť previazanosť aplikácií elimináciou veľkých zdieľaných databázových štruktúr, stále je výrazne vysoká. Jednotlivé procesy konzumenta sú závislé od volaných funkcionalít, pretože volania sú priamo implementované do procedúr systému. Toto môže v konečnom dôsledku viesť k nemožnosti zavedenia zmien na strane poskytovateľa, ktoré by neovplyvňovali externé prostredie. Na druhej strane, ak je implementovaný biznis proces, ktorý požaduje veľa synchrónnej komunikácie medzi aplikáciami, volanie vzdialených procedúr môže byť vhodná voľba. V rámci softvérovej architektúry sa pojem volanie vzdialenej procedúry profiluje aj ako prístup ku architektúre webových služieb (RPC-style web service architecture), ale v rámci metodiky integrácie volanie vzdialenej procedúry vystupuje ako technická realizácia prepojenia dvoch systémov v zmysle volania vzdialených funkcionalít/metód na úrovni inštancií objektov bez využitia zasielania správ. Zaužívaný je aj pojem Distributed Object Integration alebo Remote Procedure Invocation. Metodika integrácie IS VS 13/51

14 Výhody a nevýhody implementácie: Oblasť pre zhodnotenie Výhody Nevýhody Správa dát v aplikáciách Ak aplikácia potrebuje údaje, X vie ich požiadať zo zdrojovej aplikácie zavolaním príslušného rozhrania. Každá aplikácia si spravuje vlastnú integritu údajov a zmena údajov nemá vplyv na procesy využívajúce už existujúce rozhrania. Rôzne požiadavky na štruktúru dát Aplikácia dokáže poskytnúť X viacero rozhraní pre rôzne aplikácie spolu s inou požadovanou výstupnou štruktúrou údajov Výkonnosť a spoľahlivosť X Veľký rozdiel medzi výkonnosťou a spoľahlivosťou medzi volanými lokálnymi a vzdialenými metódami, ktoré môže viesť ku pomalým a nestabilným integračným riešeniam. Predvolená synchrónnosť. Bezpečnosť Z dôvodu publikovania rozhrania pre konzumentov je možné implementovať členitý model bezpečnosti. V prípade prístupu je možné určiť pravidlá prístupu na úrovni objektu tzn. volajúci objekt bude mať prístup iba na údaje spadajúce pod jeho rolu. Z dôvodu komplexnejšieho modelu bezpečnosti musí poskytovateľ implementovať korektné postupy pre správu užívateľských účtov pre prístup k zavolaniu metód Zasielanie správ Prenos súborov a zdieľanie databáz dovoľuje systémom využívať ich dáta, ale nie funkcionalitu. Volanie vzdialených procedúr umožňuje využitie funkcionality, ale vytvára výraznú závislosť medzi procesmi a komponentmi. Často je integračným zámerom vytvorenie kolaborácie medzi odlišnými aplikáciami včas, s minimálnym previazaním a zabezpečením spoľahlivosti z pohľadu prevádzky a ďalšieho vývoja aplikácie. Zasielanie správ sa používa v prípade keď potrebujeme zabezpečiť prenos dát často, okamžite, spoľahlivo a s použitím definovaných dátových formátov. Obrázok 2-10: Implementácia integrácie zasielanie správ (message bus, point-to-point) Zasielanie správ dokáže zabezpečiť integráciu medzi aplikáciami, ktorá pokrýva využívanie vzdialených funkcionalít (príkazová správa), prenos údajov (dokumentová správa) a zaslanie informácií o zmenách (správy udalostí), pričom komunikácia prebieha buď bod-bod (point-to-point) využitím komunikačného Metodika integrácie IS VS 14/51

15 kanálu medzi konzumentom a poskytovateľom alebo použitím dodatočného komponentu zbernice správ (message bus). Na základe štruktúry zasielaných správ a implementácie end-pointu na strane prijímateľa správy je uskutočnené spracovanie, ktoré môže zavolať požadovanú operáciu, spustiť ďalšie aktivity/procesy alebo zaevidovať informáciu o udalosti. Príkazové správy Webové služby poskytujúce operácie na základe príkazovej správy sa odporúča používať ak volajúci proces potrebuje spustenie operácie webovej služby synchrónne tzn. proces čaká až na prijatie odpovede zavolanej operácie/metódy poskytovateľa. Sú to tzv. RPC-style webové služby. Dokumentové správy Webové služby poskytujúce operácie na základe dokumentovej správy sa odporúča používať ak volajúci proces potrebuje zaslať dáta poskytovateľovi služby a neočakáva okamžitú odpoveď - tzn. vzťah medzi konzumentom a poskytovateľom je asynchrónny. Prijímateľ môže na základe zaslaných údajov spustiť potrebné spracovanie, ktoré je neviditeľné pre volajúceho. Sú to tzv. Document-style webové služby. Správy udalostí Ak chcú byť prijímatelia notifikovaní o udalosti v inej aplikácii, aby následne vykonali prislúchajúce akcie vo svojich aplikáciách, je možné implementovať zasielanie správ udalostí. Rozdiel medzi dokumentovými správami a správami udalostí nie je v štruktúre, ale v časovaní ich zaslania. Ak nastane udalosť, pre ktorú sú definovaní prijímatelia, je nutné zaslať správu o udalosti čo najskôr. Existuje viacero prístupov k implementácii komunikácie ako push alebo pull model, ktorý využívajú kombináciu príkazových, dokumentových správ a správ udalostí. V prípade implementácie integrácie cez zasielanie správ je nutné vyhodnotiť aj nasledujúce otázky: - Ako budú zasielané paketové dáta? - Kde budú zaslané dáta? - Aké dátové štruktúry majú mať správy? - Ako bude realizované zasielanie správ? - Ako sú popísané komunikačné rozhrania (end-pointy) a ich metódy? Výhody a nevýhody implementácie: Oblasť pre zhodnotenie Výhody Nevýhody Dostupnosť aplikácií/ odozva Previazanosť aplikácií Multi- broadcasting (zasielanie správ na viacerých príjemcov) Frekvencia zasielania / včasnosť údajov Testovanie a debug Zasielanie správ nevyžaduje dostupnosť aplikácií v rovnakom čase. Dokáže zabezpečiť voľnú väzbu (loose coupling) aplikácií ako v prípade prenosu súborov. Taktiež správy môžu byť transformované počas prenosu a aplikácia príjemcu a volajúceho nemusia o tejto transformácií vedieť Z dôvodu voľnej väzby je možné vysielať správu na viac ako jedného príjemcu (publish, subscribe) Zasielaním menších dát s vysokou frekvenciou na základe event-driven (správy udalosti) princípu je možné zabezpečiť dátovú konzistenciu medzi systémami. Existujú etablované platformy pre integračný vývoj a testovanie Metodika integrácie IS VS 15/51 X X X X Testovanie a debug je v tomto prístupe pomerne komplikovanejšie (treba validovať vnútornú funkcionalitu ako aj transformačnú logiku zasielaných a prijatých správ spolu s ošetrením chybových

16 Oblasť pre zhodnotenie Výhody Nevýhody Bezpečnosť Je možné definovať zabezpečenie vo forme klientskej autentifikácie, autorizačnej politiky a SSL transportu, čím je možné zabezpečiť dôvernosť a integritu prenášaných správ. hlásení z aplikácií poskytovateľov) Nutné konsolidovať interný bezpečnostný model voči bezpečnostnému modelu externých konzumentov. (Kto môže prijímať aké správy, Kto môže využívať operácie, atď.) Webové služby a výhody/nevýhody implementačných prístupov SOAP a REST Súčasťou technickej realizácie integrácie vo forme zasielania správ je rozhodnutie o implementácii komunikačných rozhraní (end-pointov). V rámci integračného vzoru zasielania správ sa etablovala technológia webových služieb. Všetky webové služby fungujú na základe komunikácie vo forme zasielania správ, rozdiel je v tom, ako je zaslaná správa štruktúrovaná a ako je prevedené volanie webovej služby. Webové služby dokážu pokryť požiadavky konzumentov pre využívanie funkcionalít vzdialených systémov (tzv. RPC-style webové služby) a zasielanie štruktúrovaných dát (document style webové služby). Je možné zvoliť viaceré prístupy k implementácii webových služieb a cieľom metodiky nie je publikácia všetkých technologických prevedení webových služieb. Uvedieme výhody aj nevýhody dvoch najviac využívaných prístupov k návrhu a implementácii webových služieb SOAP (Simple Object Access Protocol) a REST (Representational State Transfer). SOAP špecifikuje štandardný komunikačný protokol pre komunikáciu vo forme zasielania správ v XML formáte, pričom REST je prístup (sada pravidiel) k modelovaniu architektúry prenosu dát cez štandardizované rozhranie (ako napr. HTTP). Prístup Výhody Nevýhody SOAP REST Nezávislý na platforme a jazyku. Poskytuje štandard pre popis komunikačného rozhrania webovej služby (WSDL) Môže byť použitý cez viaceré protokoly (http, https, smtp,...) Spoľahlivosť a bezpečnosť (komunikácia aj cez https) a využívanie rozšírení WS- Security zabezpečujúci end-to-end zabezpečenie komunikácie Dávka (Payload) správy môže byť dodatočne enkryptovaná využitím symetrického kľúča Rozšírenie WS-ReliableMessaging môže byť implementované pre zvýšenie spoľahlivosti doručenia správ v prípade softvérových, sieťových a systémových zlyhaní. Zabudovaná správa chybových hlásení, ktorá uľahčuje testovanie doručovania správ Spracovanie asynchrónnej komunikácie Jednoduchosť implementácie na strane klienta Štruktúra správ vo formáte XML zvyšuje implementačnú záťaž na strane konzumenta a poskytovateľa a spomaľuje komunikáciu z dôvodu rozloženia správy (z angl. parsing) V prípade využitia protokolu http/https pre zasielanie správ bez využitia rozšírenia WS- Adressing sú konzument a poskytovateľ previazaný fixne. (Odpoveď je zaslaná vždy na volajúci end-point) Poskytovateľ webovej služby a konzument musia rozumieť kontextu a obsahu prenášaných údajov, pretože neexistuje štandardizovaný postup pre popis rozhraní REST webových služieb. Metodika integrácie IS VS 16/51

17 Prístup Výhody Nevýhody Webové služby sú kompletne bezstavové (stateless) Poskytujú dobrú výkonnosť v prípade metódy HTTP GET (využitie hlavne pri čítacích webových službách s pomerne statickými dátami. ) Využiteľnosť služieb je hlavne pre mobilné zariadenia a PDAs, kde konzumenta odbremeňuje pri volaní od špecifikácie dodatočných parametrov ako hlavičky správ a iné elementy (napr. parametre SOAP) Efektívne hlavne pri jednoduchých transakciách typu CRUD (create, read, update, delete). 2.3 Výber integračného vzoru a implementácie integrácie Samotný výber integračného vzoru by mal byť usmernený stratégiou a princípmi postavenými na úrovni podniku (2.3.1). Často princípy, resp. stratégia len zúžia výber integračného vzoru, ale nezaručia výber samotnej implementácie integrácie, ktorú treba vybrať na základe zhodnotenia rôznych faktorov (2.3.2) Princípy pre výber vzoru integračnej architektúry Rozhodnutia na úrovni architektúry sa opierajú o princípy. Definujú rámec plnenia strategických cieľov, okrem iného aj na úrovni architektúry (a integrácie), aj technickej realizácie. Dobre definovaný princíp by mal obsahovať názov, definíciu, účel a zdôvodnenie, implikáciu. Keďže princípy vychádzajú zo stratégie organizácie, sú vždy špecifické. Napríklad: Všetky dáta musia byť manažovateľné rovnakým postupom. Manažovanie dát ako jedna informačná entita (záznam) zjednoduší audit a údržbu dát podľa definovanej legislatívy. Dáta musia byť indexované, aby mohli byť asociované do záznamov a bude nevyhnutné implementovať DMS (Document Management System). Princípy môžu byť rozdelené do nasledovných skupín: - Biznis a legislatívne princípy (napríklad NKIVS, pripravovaný zákon o elektronickom výkone verejnej moci); - Dátové princípy (napríklad: Výnos o štandardoch pre informačné systémy verejnej správy) - Aplikačné princípy (napríklad: Výnos o štandardoch pre informačné systémy verejnej správy); - Technologické princípy (napríklad: Výnos o štandardoch pre informačné systémy verejnej správy) Faktory pre výber implementácie integrácie Rozhodnutie o výbere implementácie integrácie by malo zohľadňovať nasledujúce faktory: - Snaha o minimalizáciu previazania aplikácií voľná väzba Integrované aplikácie by mali zabezpečiť minimalizáciu potrebných predpokladov pre využívanie jednotlivých funkcionalít medzi aplikáciami (loose coupling) tzn. čo najviac vystupovať ako black-box. Týmto spôsobom je možné zabezpečiť kontinuálny vývoj jednotlivých aplikácií bez výrazných obmedzení voči ostatným aplikáciám. Vytvorené rozhranie integrovaných aplikácií by malo byť dostatočne špecifické, aby dokázalo implementovať požadovanú funkcionalitu, ale taktiež dostatočne všeobecné, aby bolo možné implementáciu v prípade potreby zmeniť. - Jednoduchosť integrácie Počas implementácie integrácie by sa mali implementátori usilovať minimalizovať zásahy do aplikácií a minimalizovať potrebné množstvo integračného kódu. Metodika integrácie IS VS 17/51

18 - Technológie integrácie Rozličné integračné vzory požadujú rôzne množstvo potrebných softvérových a hardvérových prostriedkov. Tieto prostriedky môžu byť významne finančne nákladné a taktiež je nutné vyhodnotiť potrebné zdroje pre zaškolenie personálu pre správu nových komponentov v infraštruktúre. Pri voľbe technológie integrácie sa odporúča vyhodnotiť cost vs. benefit jednotlivých technológií so zameraním sa na cenu technológie, údržbu, licencie a povahu biznis procesov v rámci inštitúcie. - Dátové formáty Integrované aplikácie sa musia dohodnúť na formáte dát, ktoré si vymieňajú, alebo disponovať pomocným prekladačom, ktorý bude zjednocovať aplikácie fungujúce na rôznych dátových formátoch. Pri definícii dátového formátu je nutné aplikovať platné štandardy v rámci inštitúcie, aby sa predišlo dátovým nekonzistenciám pri integrácii jednotlivých subjektov. - Včasnosť údajov a objem prenášaných dát Integrácia by mala minimalizovať čas prenosu medzi aplikáciami. V prípade keď v jednej aplikácii dôjde k zmene dát, tieto by mali byť čo najskôr premietnuté do druhého systému. V prípade objemu prenášaných dát je nutné prehodnotiť technickú realizáciu integrácie a či je efektívne prenášať údaje cez online rozhrania alebo prenosom súboru. Determinácia sa odvíja od nefunkcionálnych požiadaviek kladených na kontrakt integrácie a je závislá od infraštruktúry na strane poskytovateľa, ako aj konzumenta dát. - Využívanie dát alebo funkcionality Integrované aplikácie nemusia využívať iba spoločné dáta, ale aj funkcionality, ktoré môžu medzi sebou jednotlivé aplikácie spustiť. Vzdialené spustenie funkcionalít môže byť náročnejšie po implementačnej stránke a aj keď môže pripadať v niektorých prípadoch ako volanie lokálnych metód, fungovanie je podstatne komplikovanejšie. Vyhodnotenie povahy biznis procesu je kľúčové pri determinácií využívania dát alebo funkcionality. (Napr. biznis proces nepotrebuje kriticky aktuálne dáta; vlastníkom a správcom využívanej doménovej funkcionality je iný subjekt z dôvodu legislatívnej úpravy, atď.) - Mód komunikácie (synchrónna a asynchrónna) Počítačové spracovanie je zvyčajne vykonávané v synchrónnom móde (Napríklad procedúra čaká kým zavolaná sub-procedúra nie je ukončená). V prípade ak procedúra chce spustiť sub-procedúru a pokračovať vo svojej exekúcii, zavolá sub-procedúru asynchrónne a tá sa následne vykoná na pozadí. Tento koncept je dôležitý hlavne pre integrované aplikácie. Nedostupnosť služby z dôvodu výpadku siete alebo nefunkčnosti služby na strane poskytovateľa by v synchrónnom móde pozastavilo exekúciu na strane konzumenta. V prípade asynchornného zavolania služby môže konzument pokračovať v exekúcii svojho procesu a spracovať odpovedi po vykonaní ďalších krokov. Nie je možné zvoliť jeden globálny integračný vzor, ktorý by pokryl všetky potreby integrácie. Integračné vzory treba vyhodnotiť pre každú integračnú situáciu na základe jednotlivých princípov a faktorov. Každý z uvedených vzorov architektúry a implementácie má svoje výhody a nevýhody. Je možné integrovať aplikácie viacerými rôznymi vzormi a technickými realizáciami, kde každá požadovaná funkcionalita bude implementovaná spôsobom, ktorý je pre ňu najviac vhodný. Potenciálne výhody a nevýhody vzorov architektúry a implementácie integrácie: Integračný vzor z pohľadu architektúry Integrácia pomocou informačného portálu Možná implementácia Spúšťanie vzdialených procedúr Zasielanie správ Výhody Biznis logika zabudovaná a udržiavaná vlastníkmi doménovej funkcionality Zabezpečená voľná väzba, ktorá umožňuje flexibilitu Synchronizácia dát Prenos súborov Možnosť prenosu veľkého objemu dát. Nevýhody Informačný portál je výrazne previazaný s poskytovanými funkcionalitami a zmeny môžu mať vysoký dopad na prezentačnú vrstvu. Nutné transformačné algoritmy pre mapovanie objektov prezentačnej vrstvy Včasnosť údajov nemusí spĺňať požiadavky niektorých procesov Metodika integrácie IS VS 18/51

19 Integračný vzor z pohľadu architektúry Zdieľané biznis funkcionality SOA architektúra Distribuované biznis procesy Integrácia B2B Možná implementácia Zdieľaná databáza Spúšťanie vzdialených procedúr Zasielanie správ Spúšťanie vzdialených procedúr Zasielanie správ Spúšťanie vzdialených procedúr Zasielanie správ Spúšťanie vzdialených procedúr Zasielanie správ Výhody Včasnosť údajov a konzistencia na centralizovanom mieste Je možné implementovať atomické rozhrania pre synchronizáciu dát rôznych tabuliek/databáz Pri definovaní vysokej frekvencie zasielania správ je možné maximalizovať včasnosť údajov Centralizácia funkčnosti a minimalizácia redundancie. Intuitívna implementácia (ako volanie lokálnych procedúr) Schopnosť transformácie správ do definovaných formátov zabezpečuje prepojenie aplikácií cez voľnú väzbu Enkapsulácia integrovaných aplikácií. (Každá aplikácia spravuje sama integritu svojich dát ) Jednotlivé systémy vystupujú ako black-box so štandardizovaným popisom rozhraní dostupným v katalógu služieb Možnosť modelovania procesov už z existujúcich služieb, kde sa využíva iba volanie týchto služieb. Možnosť modelovania procesov už z existujúcich služieb, kde sa využíva iba volanie týchto služieb. Špecifický prípad Nevýhody Porušenie základného SOA princípu - strata voľnej väzby medzi aplikáciami. Z dôvodu viacnásobných prístupov k dátam, môžu vzniknúť prevádzkové problémy (napr. proces edituje záznam, pričom iný proces vyžaduje prístup na záznam). Možnosť prenosu iba pomerne nízkeho objemu dát. Možnosť prenosu iba nízkeho objemu dát. Nutné implementovať transformačné komponenty medzi jednotlivými aplikáciami. Väčšia implementačná záťaž. V niektorých prípadoch môže vzniknúť výrazné previazanie aplikácií z pohľadu funkčnosti, čo nie je v súlade so SOA princípmi. Väčšia implementačná záťaž. Nutné nasadiť platformu pre orchestráciu služieb; Implementácia transformačných komponentov Nutné nasadiť platformu pre orchestráciu služieb; Implementácia transformačných komponentov Samotná analýza princípov Informatizácie verejnej správy a integračných scenárov je v kapitole 3. Metodika integrácie IS VS 19/51

20 3 Vyhodnotenie integračných vzorov voči princípom elektronizácie VS SR Nasledujúca kapitola vyhodnocuje aplikovanie integračných vzorov v rámci informatizácie VS SR. V prvom kroku sa analyzujú špecifické požiadavky resp. princípy elektronizácie VS SR z pohľadu NKIVS a Zákona 275/2006 o informačných systémov a o zmene a doplnení niektorých zákonov a Výnos Ministerstva financií Slovenskej republiky č. 312/2010 o štandardoch pre informačné systémy verejnej správy. Následné tieto požiadavky / princípy sú aplikované na jednotlivé integračné vzory a technologickú realizáciu integrácie v rámci priloženého súboru analýzy. V závere je definované sumárne zhrnutie tejto analýzy a detailné informácie sú dostupné v dokumente: Matica_vyhodnotenie_integracia_VSSR.xlsx. 3.1 Princípy integrácie ISVS Zdrojom požiadaviek princípov kladených na integráciu ISVS sú: Národná koncepcia informatizácie verejnej správy, Zákon 275/2006 o informačných systémov a o zmene a doplnení niektorých zákonov a Výnos Ministerstva financií Slovenskej republiky 312/2010 o štandardoch pre informačné systémy verejnej správy. Vstupom boli samotné dokumenty resp. výstupy projektu Implementácia programovej kancelárie OPIS, rozšírením projektovej kancelárie systémov riadenia verejných financií. Z ktorých boli identifikované princípy s dopadom na integráciu. Zoznam jednotlivých princípov je v prílohe Matica_vyhodnotenie_integracia_VSSR.xlsx - stĺpec princípy. Avšak zároveň treba vypichnúť nasledovné hlavné vlastnosti integrácie v rámci informatizácie VS SR: Informačné systémy, resp. softvérové aplikácie verejnej správy musia byť schopné vzájomnej komunikácie, t. j. vzájomne spolupracovať, využívať a vymieňať si údaje; Musia byť postavené na takých technológiách, ktoré umožnia vytváranie navzájom prepojených a spolupracujúcich ISVS, rešpektujúcich požiadavky používateľov (občanov, podnikateľov a verejnej správy) na poskytovanie efektívnych a kvalitných služieb; Pri vytváraní ISVS je nevyhnutné uplatňovať procesný prístup, ktorý je východiskom pre tvorbu architektúry integrovaného ISVS; Interoperabilita komponentov integrovanej architektúry ISVS bude zabezpečená prostredníctvom webových služieb, ktorých špecifikácia bude štandardizovaná a popísaná pomocou jazyka WSDL. Štandardom pre výmenu údajov v rámci využívania web služieb bude jazyk XML, ktorého štruktúry budú štandardizované a popísané pomocou schémy XSD. Informačné systémy, ktoré poskytujú webové služby ich uverejňujú v katalógu webových služieb, tzn. v rámci architektúry katalóg webových služieb je principiálnym nástrojom pre získanie informácií o webových službách a preto je potrebné určité atribúty poskytovaných služieb zadávať už v procese plánovania; Dodatočne uvádzame aj zhrnutie základných filozofických a prípadných technických požiadaviek na integráciu ISVS v prípade integračnej architektúry v zmysle SOA a technickej implementácie zasielania správ: Požiadavka Tech. Požiadavka Štandardy Autonómnosť aplikácií Poskytovanie funkčností vo forme webových služieb Failure and Security isolation Klastrovateľný aplikačný server Popis služby JAX-*, WS-*, WS-I. WSDL Registrácia služby UDDI register v. 3.0 Štandardná komunikácia služby Výmena správ niektorými štandardnými protokolmi ako JMS, HTTP, SOAP over JMS, Metodika integrácie IS VS 20/51

21 Požiadavka Tech. Požiadavka Štandardy SOAP over HTTP Životný cyklus IS musí podliehať riadenému životnému cyklu SOA služieb Integrácia používateľského rozhrania Integrácia na ESB Popis procesov pokrývaných vnútorne v IS Releasovanie IS je identifikované aj na zmeny procesov a služieb Využívanie grafického rozhrania centrálneho portálu Obalenie sluţieb Portletmi Podpora centrálneho Identity managementu a SSO Aplikačný adaptér pre príslušnú zbernicu (technológiu) BPMN, BPEL Podľa výsledkov špecifikácie pre ÚPVS WRSP Princípy integrácie na centrálne komponenty Základné princípy integrácie ÚPVS: 3.2 Integrácia realizovaná prostredníctvom webových služieb; Integračné rozhrania sú vystavené v sieti Internet a/alebo Govnet; Autentifikáciu klienta je realizovaná SAML tokenom vydávaným modulom IAM (služba STS) Autentifikácia IS je realizovaná technickým certifikátom Počet špecializovaných integračných rozhraní je minimalizovaný, väčšina služieb je poskytovaných prostredníctvom univerzálnych synchrónnych a asynchrónnych rozhraní Väčšina služieb je realizovaných ako asynchrónne v záujme minimalizácie závislosti integrovaných systémov z hľadiska dostupnosti Aplikovanie princípov integrácie ISVS voči integračným scenárom a technickej realizácií integrácie Výsledok aplikovania princípov integrácie ISVS voči integračným vzorom a technickej realizácií integrácie je zobrazený prostredníctvom matice. Matica obsahuje na osi X vymenované integračné scenáre a technické realizácie integrácie a na osi Y jednotlivé princípy integrácie. Jednotlivé prvky matice odpovedajú na otázku Je vybraný princíp integrácie naplnený integračným scenárom alebo technickou realizáciou? Odpoveď môže byť Áno ( OK ), Nie ( X ) alebo Ne aplikovateľné ( N/A ). V nasledujúcej tabuľke sú vybrané príklady jednotlivých typov odpovede: Typ odpovede: Áno Nie Ne aplikovateľné Príklad: Integrácia pomocou integračného portálu podporuje prenos dát prostredníctvom Hypertext Transfer Protocol (HTTP). HTTP je defacto priemyselným štandardom na prenos údajov medzi používateľom a ISVS a ISVS-ISVS prostredníctvom webových služieb implementovaných protokolom SOAP. Integrácia pomocou integračného portálu nepodporuje prenos dát prostredníctvom File Transfer Protocol. Integrácie pomocou integračného portálu vyžaduje on-line komunikáciu ISVS-ISVS pre zabezpečenie uspokojivej používateľskej skúsenosti, pričom FTP protokol sa v bežnej praxi chápe ako protokol pre služby s požiadavkami na radové vyššie časy odozvy systémov. Princíp použitia XHTML pri prenose dát medzi klientom a webovým serverom je neaplikovateľná na scenár Integrácie B2B. Keďže tento scenár integrácie integruje dva alebo viacej ISVS a nie klienta ako používateľa. Metodika integrácie IS VS 21/51

22 Matica vyhodnotenia: Matica_vyhodnotenie_integracia_VSSR.xlsx Popis štruktúry súboru: V priloženom súbore sú vyhodnotené princípy pre ISVS SR voči používaným integračným vzorom v rámci podnikových IS. Súbor má nasledovné atribúty: - Dokument (Zdroj pre princíp) o Názov o Oblasť - Skupina (Skupina princípov pre vyhodnotenie) - Princíp (Princíp kladený na integráciu a architektúru ) - Poradové číslo (Poradové číslo princípu) - Architektúra integrácie (Jednotlivé typy architektúry) - Technická realizácia integrácie (Jednotlivé typy implementácie integrácie) Vyhodnotenie princípov: - OK (Ak je integračný vzor v súlade s princípom) - N/A (Princíp nie je aplikovateľný pre integračný vzor) - X (Ak je integračný vzor v rozpore s princípom) Metodika integrácie IS VS 22/51

23 3.3 Zhrnutie aplikácie integračných vzorov v rámci elektronizácie VS SR Na základe analýzy aplikovania princípov integrácie ISVS voči integračným vzorom a technickej realizácií integrácie boli identifikované výsledky analýzy. Nasledujúci zoznam uvádza niektoré hlavné zistenia analýzy: 1. Implementácia integrácie (integračných vzorov) prostredníctvom zdieľania databáz a volanie vzdialených procedúr nie je odporúčané, z dôvodu popierania princípov NKIVS a štandardov. 2. Technická realizácia integrácie prostredníctvom prenosu súborov (používanie protokolu File transfer protokol (FTP)) nevyhovuje v oblasti štandardov webových služieb. Avšak je odporúčané používať tento protokol ako pridružený, hlavne pri prenosoch veľkých objemov dát. 3. V prípade štandardov pre webové služby je možné implementovať všetky integračné architektúry, pričom technická realizácia zasielania správ a implementácia webových služieb (end-pointov) musí byť uskutočnená v zmysle SOAP vo verzii 1.2 a vyššie a komunikačné rozhranie musí byť definované pomocou WSDL. 4. Špecifikácia formátu prenášaných údajov v štruktúre Extensible Markup Language (.xml) vo verzii 1.0 podľa Word Wide Web (W3C) má vplyv na technickú realizáciu integrácie vo forme prenosu súborov a zasielania správ, kde jednotlivé prenášané údaju musia byť iba vo formáte XML. 5. Princíp ohľadom technologickej infraštruktúry verejnej správy, ktorá musí byť flexibilná, t. j. taká, ktorá z dôvodu zmien v štruktúre verejnej správy, najmä na výkonnej úrovni, ako aj inovácií aplikácií vyžaduje investične nenáročné úpravy determinuje využitie integračných architektúr zabezpečujúcich voľnú väzbu. Detailné vyhodnotenie je v priloženom dokumente: Matica_vyhodnotenie_integracia_VSSR.xlsx Dokument Architektúra integrácie Technicka realizácia integrácie Názov Oblasť Skupina princípov Používanie sieťového protokolu Internet Protocol vo verzii 4 (IP v4) spolu s protokolmi Transmission Control Protocol Výnos o štandardoch Štandardy pre prepoje Technologické prin (TCP) a User Datagram Protocol (UDP) pre informačné systémy verejnej správy Zavádzanie nových systémových komponentov, ktoré popri sieťovom protokole Internet Protocol vo verzii 4 (IP v4) Výnos o štandardoch Štandardy pre prepoje Technologické prin podporujú aj sieťový protokol Internet Protocol vo verzii 6 (IP v6) a podporujú sieťovú technológiu Dual stack Používanie skupiny protokolov Internet Protocol Security Výnos o štandardoch Štandardy pre prepoje Technologické prin (IPSEC) na zabezpečenie sieťových protokolov. Princíp ID evaluation area Integrácia Synchr Zdieľan SOA Distribuo Spúštanie Integráci Prenos Zdieľaná Zasielanie pomocou onizác é biznis architekt vané vzdialených a B2B súborov databáza správ informačného ia dát funkcio úra biznis procedúr 1 N/A N/A N/A N/A N/A N/A N/A N/A N/A 2 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 3 N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A Výnos o štandardoch Prenos dát Technologické prinpoužívanie protokolu File Transfer Protocol (FTP) 4 N/A OK X X X X OK X X X Prenos dát Technologické prinpoužívanie protokolu Hypertext Transfer Protocol (HTTP) 5 OK OK OK OK OK OK OK X X OK Výnos o štandardoch Prenos dát Špecifikácie pre Výnos o štandardoch prepojenie pomocou sieťových služieb Aplikačné protokoly Výnos o štandardoch elektronických služieb Aplikačné protokoly Výnos o štandardoch elektronických služieb Aplikačné protokoly Výnos o štandardoch elektronických služieb Aplikačné protokoly Výnos o štandardoch elektronických služieb Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch Štandardy pre webové služby Štandardy pre webové služby Štandardy pre webové služby Štandardy pre webové služby Štandardy pre webové služby Štandardy pre webové služby Podpora chráneného prenosu dát cez kryptografický protokol Secure Sockets Layer (SSL) minimálne vo verzii 3.0 alebo Technologické prin Transport Layer Security (TLS). Technologické prinštandardom pre špecifikácie pre prepojenie pomocou sieťových služieb je používanie Domain Name Services (DNS) ako hierarchickej služby name servera v centrálnych bodoch internetu. Používanie protokolu Hypertext Transfer Protocol (HTTP) vo verzii 1.1 s prenosom dát vo formáte Extensible HyperText Technologické prin Markup Language (XHTML) vo verzii 1.0 na komunikáciu medzi klientom a webovým serverom, Podpora protokolu Hypertext Transfer Protocol Technologické prin(http) vo verzii 1.1 a Hypertext Transfer Protocol (HTTP) vo verzii 1.0 pri webových serveroch Používanie mechanizmu Hypertext Transfer Protocol State Management Mechanism (HTTP Management Technologické prin Mechanism) na Hypertext Transfer Protocol Session Management (HTTP Session Management) a cookies Používanie protokolu Hypertext Transfer Protocol over Secure Sockets Layer (HTTPs) alebo Transport Technologické prinlayer Security (TLS) pri chránenom prenose dát medzi klientom a webovým serverom a medzi webovými servermi. Používanie protokolu Simple Object Access Protocol (SOAP) minimálne vo verzii 1.2 pri komunikácii medzi servermi Aplikačné princípy v rámci jednej správy a komunikácii medzi klientom a serverom Používanie webových služieb na prístup klientskych aplikácií Aplikačné princípy prostredníctvom internetu na serverové aplikácie správy, Používanie protokolu Hypertext Transfer Protocol (HTTP) na poskytnutie vrstvy webovej služby pre existujúcu Aplikačné princípy serverovú aplikáciu a komunikáciu na aplikačnej úrovni, Používanie jazyka Web Services Description Language (WSDL) Aplikačné princípy na definíciu webovej služby, Používanie registra Universal Description, Discovery and Integration Aplikačné princípy (UDDI) minimálne vo verzii 1.0 na komunikáciu medzi klientom a serverom, špecifikácií pre mapové služby pod 1. OpenGIS WebMap Service (WMS), 2. OpenGIS Web Feature Service (WFS), Aplikačné princípy 3. OpenGIS Web Coverage Service (WCS), 4. OpenGIS Web Processing Service (WPS), 5. OpenGIS Catalog Service for Web (CSW) OK OK OK OK OK OK OK X X OK N/A N/A N/A N/A N/A N/A N/A X N/A N/A OK N/A N/A N/A N/A N/A N/A X N/A N/A OK N/A N/A N/A N/A N/A N/A X N/A N/A OK N/A N/A N/A N/A N/A N/A X N/A N/A OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK OK N/A OK OK OK N/A X X N/A OK Výnos o štandardoch Štandardy pre integrácdátové princípy Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch Výnos o štandardoch NKIVS NKIVS NKIVS NKIVS Prenos dátových prvkov Prenos dátových prvkov Prenos dátových prvkov Prenos dátových prvkov Prenos dátových prvkov Formovanie infraštruktúry Dátové princípy Dátové princípy Dátové princípy Dátové princípy Dátové princípy Štandardom pre popisný jazyk pre dátové prvky je používanie jazyka Extensible Markup Language (XML) podľa World Wide Web Consortium (W3C) pre dátové prvky pri vstupe na rozhranie informačného systému verejnej správy. Používanie jazyka schém XML Schema Definition (XSD) minimálne vo verzii 1.0 na výmenu dátových prvkov medzi všetkými informačnými systémami verejnej správy nezávisle od účelu správy, Používanie formátu Extensible Markup Language (.xml) vo verzii 1.0 podľa Word Wide Web (W3C) pri výmene dátových prvkov, Používanie špecifikácie znakovej sady Unicode Transformation Format (UTF), a to 8-bitové kódovanie UTF-8 pre integráciu údajov, Používanie transformačného jazyka XSL Transformations (XSLT) podľa World Wide Web Consortium (W3C) pri transformácii dátových prvkov Používanie modelovacieho jazyka Geography Markup Language (GML) pri výmene priestorových údajov Informačné systémy, resp. softvérové aplikácie verejnej správy musia byť schopné vzájomnej komunikácie, t. j. Biznis a legislatívne vzájomne spolupracovať, využívať a vymieňať si údaje Technologická infraštruktúra verejnej správy musí byť flexibilná, t. j. taká, ktorá z dôvodu zmien v štruktúre verejnej Formovanie infraštruktbiznis a legislatívne správy, najmä na výkonnej úrovni, ako aj inovácií aplikácií vyžaduje investične nenáročné úpravy Musí byť postavená na takých technológiách, ktoré umožnia vytváranie navzájom prepojených a spolupracujúcich ISVS, Formovanie infraštruktbiznis a legislatívnerešpektujúcich požiadavky používateľov (občanov, podnikateľov a verejnej správy) na poskytovanie efektívnych a kvalitných služieb integrovaného ISVS Výsledkom procesného prístupu je komplexný procesný model, ktorý je: Digitalizácia úsekov spbiznis a legislatívne Funkčný predstavuje súbor činností a väzby medzi nimi, ktoré sú realizované v rámci výkonu správy. Organizačný - reprezentuje štruktúru, kompetencie a prislúchajúce väzby medzi organizačnými jednotkami v rámci výkonu správy OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X N/A OK OK OK OK OK OK OK OK OK N/A OK OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X N/A OK OK OK OK OK OK OK N/A N/A N/A N/A OK OK OK OK OK OK N/A N/A N/A N/A OK OK OK OK OK OK N/A N/A N/A N/A OK OK OK OK OK OK N/A N/A N/A N/A NKIVS Architektúra IISVS Biznis a legislatívneinformačné systémy poskytujú webové služby iným informačným systémom, ktoré tieto služby môžu využívať 28 OK OK OK OK OK OK X X X OK NKIVS Architektúra IISVS Biznis a legislatívneinformačné systémy, ktoré poskytujú webové služby ich uverejňujú v katalógu webových služieb 29 OK OK OK OK OK OK X X X OK Pre každý číselník musí byť definovaná a štandardizovaná štruktúra a obsah číselníka pomocou technologického NKIVS Základné číselníky Biznis a legislatívne štandardu XSD. Definícia bude obsahovať názvy atribútov, ich údajových typov, veľkosti prípustných hodnôt 30 OK OK OK OK OK OK X X N/A OK Informačné systémy verejnej správy spravujúce číselníky by mali poskytovať e-služby sprístupňujúce aktuálny obsah NKIVS Základné číselníky Dátové princípy číselníka ako aj historické údaje (aký bol obsah číselníka v presne definovanom čase v minulosti) prostredníctvom webových služieb Každý zo základných registrov bude poskytovať minimálne nasledovnú sadu webových služieb na komunikáciu s inými NKIVS Základné číselníky Dátové princípy IS: Poskytnutie referenčných údajov jednej údajovej entity (výstup služby) na základe jednoznačného identifikátora (vstup služby). Poskytnutie referenčných údajov viacerých údajových entít (výstup služby) na základe zoznamu jednoznačných NKIVS Základné číselníky Dátové princípy identifikátorov (vstup služby). Poskytnutie zoznamu jednoznačných identifikátorov údajových entít (výstup služby), ktorých referenčné údaje boli NKIVS Základné číselníky Dátové princípy zmenené od zadaného časového úseku (vstup služby) OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK OK OK OK OK OK OK X X N/A OK NKIVS Základné číselníky Dátové princípy Základné registre budú poskytovať údaje definovaným používateľom prostredníctvom komunikačných rozhraní 35 OK OK OK OK OK OK X X OK OK NKIVS Základné číselníky Dátové princípy Aktuálne referenčné údaje základných registrov si ostatné ISVS zabezpečia tým, že si tieto údaje základného registra vyžiadajú prostredníctvom web služieb a definovaných pravidiel 36 OK OK OK OK OK OK X X OK OK NKIVS Základné číselníky Dátové princípy Integrácia základných registrov s ISVS umožní on-line poskytovanie referenčných údajov základných registrov ostatným ISVS na čítanie a zároveň ostatné ISVS budú povinne používať získané referenčné údaje k svojmu spracovaniu Referencované údaje budú získavané zo základných registrov ostatnými ISVS: on-line poskytnutím z príslušných NKIVS Základné číselníky Dátové princípy základných registrov prostredníctvom na to určených webových služieb a na základe príslušných jednoznačných identifikátorov Referencované údaje budú získavané zo základných registrov ostatnými ISVS: vytvorením kópií referenčných údajov z NKIVS Základné číselníky Dátové princípy prislúchajúcich základných registrov NKIVS Architektúra IS úseku Je však potrebné aby boli tieto systémy prispôsobené tak, aby dokázali poskytovať služby (v zmysle konceptu SOA) a Biznis a legislatívne správy umožnili ich integráciu s ostatnými systémami VS NKIVS Architektúra IS úseku Pre účely integrácie služieb egovernmentu do informačných systémov verejnosti (najmä IS komerčných subjektov) Biznis a legislatívne správy budú vybrané e-služby sprístupňované prostredníctvom webových služieb Po vyžiadaní služby prostredníctvom webových služieb, bude výstup služby poskytnutý komunikačnými protokolmi Architektúra IS úseku NKIVS Biznis a legislatívneurčenými na využívanie webových služieb, takže tento výstup bude možné spracovať informačným systémom subjektu správy žiadajúceho o poskytnutie danej služby NKIVS Katalóg webových služieb, označovaný Universal Description, Discovery and Integration (ďalej len UDDI ), bude Ostatné komponenty Biznis a legislatívneposkytovať prostriedky na zaregistrovanie, evidenciu, kategorizáciu a vyhľadávanie webových služieb (web services) v rámci celkovej architektúry IISVS OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X X X OK OK OK OK OK OK OK X X OK OK OK OK OK OK OK OK X X X OK Metodika integrácie IS VS 23/51