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

51 

Texto

(1)

Metodika integrácie IS VS

Všeobecné informácie

(2)

Metodika integrácie IS VS

2/51

Obsah

1

C

IELE A

VÝCHODISKÁ METODIKY

... 4

OČAKÁVANIA OD METODIKY ...4

1.1 CIELE METODIKY ...5 1.2 VÝCHODISKÁ METODIKY ...5 1.3 PREDPOKLADY ...5 1.4 ČO NIE JE PREDMETOM METODIKY ...6

1.5

2

I

NTEGRA

Č

NÉ VZORY

(B

EST PRACTICES

) ... 7

INTEGRAČNÉ VZORY ZPOHĽADU ARCHITEKTÚRY ...7

2.1 2.1.1 Integrácia vo forme informačného portálu ...7

2.1.2 Integrácia cez synchronizáciu dát ...7

2.1.3 Integrácia na zdieľané biznis funkcionality ...8

2.1.4 Integrácia v zmysle SOA architektúry ...9

2.1.5 Integrácia vo forme distribuovaného biznis procesu ...9

2.1.6 Integrácia B2B ... 10

INTEGRAČNÉ VZORY ZPOHĽADU IMPLEMENTÁCIE ... 10

2.2 2.2.1 Prenos súborov... 10

2.2.2 Zdieľané databázy ... 12

2.2.3 Volanie vzdialenej procedúry ... 13

2.2.4 Zasielanie správ... 14

VÝBER INTEGRAČNÉHO VZORU AIMPLEMENTÁCIE INTEGRÁCIE ... 17

2.3 2.3.1 Princípy pre výber vzoru integračnej architektúry ... 17

2.3.2 Faktory pre výber implementácie integrácie ... 17

3

V

YHODNOTENIE INTEGRA

Č

NÝCH VZOROV VO

Č

I PRINCÍPOM ELEKTRONIZÁCIE

VS

SR 20

PRINCÍPY INTEGRÁCIE ISVS ... 20

3.1 3.1.1 Princípy integrácie na centrálne komponenty ... 21

APLIKOVANIE PRINCÍPOV INTEGRÁCIE ISVS VOČI INTEGRAČNÝM SCENÁROM ATECHNICKEJ REALIZÁCIÍ 3.2 INTEGRÁCIE ... 21

ZHRNUTIE APLIKÁCIE INTEGRAČNÝCH VZOROV VRÁMCI ELEKTRONIZÁCIE VSSR ... 23

3.3

4

Ž

IVOTNÝ CYKLUS INTEGRA

Č

NÉHO ZÁMERU

... 24

PROJEKTOVÉ AORGANIZAČNÉ AKTIVITY INTEGRAČNÉHO ZÁMERU ... 26

4.1 4.1.1 Úloha: Dohoda o integračnom zámere ... 26

4.1.2 Úloha: Projektové riadenie, eskalácia a manažment rizík, monitorovanie ... 28

4.1.3 Úloha: Vypracovanie dohody o poskytovaní služieb a manažmentu post-implementačných zmien 28 DEFINOVANIE ROZSAHU INTEGRÁCIE - PROCESNÝ/LOGICKÝ ATECHNICKÝ NÁVRH ... 30

4.2 4.2.1 Úloha: Aktualizácia katalógu poskytovaných služieb ... 31

(3)

Metodika integrácie IS VS

3/51

4.2.3 Úloha: Špecifikácia služieb ... 35

4.2.4 Úloha: Integračný technický návrh ... 38

INFRAŠTRUKTÚRA A IMPLEMENTÁCIA INTEGRAČNÉHO ZÁMERU ... 39

4.3 4.3.1 Úloha: Prepojenie infraštruktúry ... 40

4.3.2 Úloha: Príprava test plánu, testovacích scenárov a prípadov ... 41

4.3.3 Úloha: Vývoj komponentov pre integráciu ... 43

4.3.4 Úloha: Vykonanie integračných testov ... 44

4.3.5 Úloha: Vykonanie používateľských akceptačných testov ... 45

4.3.6 Úloha: Zavedenie do prevádzky, monitoring ... 45

5

P

RÍLOHY

... 47

MAPOVANIE AKTIVÍT V RÁMCI METODIKY INTEGRÁCIE NA ÚROVNE INTEROPERABILITY KLADENÉ VRÁMCI 5.1 EIF 47 MAPOVANIE VZOROV VO FORME DÁVKOVÉHO PRENOSU, PUSH, PULL A ONLINE NA VZORY TECHNICKEJ 5.2 IMPLEMENTÁCIE METODIKY INTEGRÁCIE ... 49

ZOZNAM PRACOVNÝCH PRODUKTOV METODIKY INTEGRÁCIE ... 50

5.3

6

R

EFERENCIE

... 51

(4)

Metodika integrácie IS VS

4/51

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

O

č

akávania od metodiky

1.1

• 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;

(5)

Metodika integrácie IS VS

5/51

Ciele metodiky

1.2

Číslo cieľa Cieľ metodiky Referencia cieľa v metodike 1. Definovať základné časti, typy a architektúru

integrácie;

2.1, 2.2 2. Popísať princípy a pravidlá integrácie (best

practice)

2.3, 3.1, 3.2, 3.3 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.1.1,

4. Definovať základné požiadavky integrácie na úrovni:

- služieb (procesné modely služieb),

4.2.1, 4.2.2, 4.2.3 5. Definovať základné požiadavky integrácie na

úrovni:

- technickej (rozhrania, tech. dokumentácia, komunikačná infraštruktúra), 4.2.4, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5, 4.3.6 6. Vymedziť nevyhnutné Vstupy / Výstupy pre

integráciu za obe strany, ktoré sa integrujú.

4

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

4.2.1

Východiská metodiky

1.3

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

1.4

Nutné predpoklady pre uskutočnenie integračného zámeru v zmysle predloženej metodiky integrácie: - Identifikované medziprojektové väzby (úroveň projekt-projekt)

(6)

Metodika integrácie IS VS

6/51

Č

o nie je predmetom metodiky

1.5

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

(7)

Metodika integrácie IS VS

7/51

2 Integra

č

né vzory (Best practices)

Integra

č

né vzory z poh

ľ

adu architektúry

2.1

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.

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

Obrázok 2-1: Integračný vzor – informačný portál Charakteristiky:

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

2.1.2 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);

(8)

Metodika integrácie IS VS

8/51

Obrázok 2-2: Integračný vzor – synchronizácia dát

Charakteristiky:

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.

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

Obrázok 2-3: Integračný vzor – zdieľané biznis funkcionality Charakteristiky:

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

(9)

Metodika integrácie IS VS

9/51

úsporu prevádzkových nákladov.

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

Obrázok 2-4: Integračný vzor - servisne orientovaná architektúra Charakteristiky:

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

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

(10)

Metodika integrácie IS VS

10/51

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.

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

Obrázok 2-6: Integračný vzor – integrácia B2B Charakteristiky:

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.

Integra

č

né vzory z poh

ľ

adu implementácie

2.2

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

2.2.1 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ť

(11)

Metodika integrácie IS VS

11/51

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 Na trhu sú už etablované

štandardizované formáty – textové súbory, csv., XML, atď.

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.

Časové hľadisko (kedy vygenerovať, kedy konzumovať) a uskladnenie dát (kde bude súbor umiestnený)

Informácie dostupné centralizovane na jednom mieste pre konzumentov

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

Previazanosť aplikácií 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.

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.

Správa a vytváranie súboru Nie sú potrebné žiadne dodatočné nástroje alebo integračné platformy

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ý) Včasnosť údajov a prenos súborov Možné preniesť veľké dávky

dát na jeden krát

Ú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

(12)

Metodika integrácie IS VS

12/51

Oblasť pre zhodnotenie Výhody Nevýhody

požadoval informácie pred synchronizáciou)

Bezpečnosť Existujú protokoly pre bezpečný prenos napr. SFTP

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.

2.2.2 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ú

rovnaké údaje.

X

Formát dát Otázky ohľadom

transformácie údajov sú eliminované

štandardizovanými

databázovými typmi DBMS. X

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,

(13)

Metodika integrácie IS VS

13/51

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 Rýchla odozva z dôvodu

priameho prístupu na databázu

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

Bezpečnosť Je možné zabezpečiť

enkryptovanie dát v rámci databázy.

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

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

(14)

Metodika integrácie IS VS

14/51

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,

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.

X

Rôzne požiadavky na štruktúru dát Aplikácia dokáže poskytnúť

viacero rozhraní pre rôzne aplikácie spolu s inou požadovanou výstupnou štruktúrou údajov

X

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.

2.2.4 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

(15)

Metodika integrácie IS VS

15/51

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 Zasielanie správ nevyžaduje

dostupnosť aplikácií v rovnakom

čase.

X

Previazanosť aplikácií 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ť

X

Multi- broadcasting (zasielanie správ na viacerých príjemcov)

Z dôvodu voľnej väzby je možné vysielať správu na viac ako jedného príjemcu (publish, subscribe)

X

Frekvencia zasielania / včasnosť údajov 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.

X

Testovanie a debug Existujú etablované platformy pre integračný vývoj a testovanie

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)

Metodika integrácie IS VS

16/51

Oblasť pre zhodnotenie Výhody Nevýhody

hlásení z aplikácií poskytovateľov)

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.

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

Nezávislý na platforme a jazyku. Poskytuje štandard pre popis komunikačného rozhrania webovej služby (WSDL)

Š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) Môže byť použitý cez viaceré protokoly

(http, https, smtp,...)

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)

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

REST

Jednoduchosť implementácie na strane klienta

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.

(17)

Metodika integrácie IS VS

17/51

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

Výber integra

č

ného vzoru a implementácie integrácie

2.3

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

2.3.1 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).

2.3.2 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“.

(18)

Metodika integrácie IS VS

18/51

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

- 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

Možná

implementácia

Výhody Nevýhody Integrácia pomocou

informačného portálu

Spúšťanie

vzdialených procedúr

Biznis logika zabudovaná a udržiavaná vlastníkmi doménovej funkcionality Informačný portál je výrazne previazaný s poskytovanými funkcionalitami a zmeny môžu mať vysoký dopad na prezentačnú vrstvu. Zasielanie správ Zabezpečená voľná väzba,

ktorá umožňuje flexibilitu

Nutné transformačné algoritmy pre mapovanie objektov prezentačnej vrstvy Synchronizácia dát Prenos súborov Možnosť prenosu veľkého

objemu dát.

Včasnosť údajov nemusí spĺňať

požiadavky

(19)

Metodika integrácie IS VS

19/51

Integračný vzor

z pohľadu architektúry

Možná

implementácia

Výhody Nevýhody Zdieľaná databáza Včasnosť údajov

a konzistencia na centralizovanom mieste

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). Spúšťanie

vzdialených procedúr

Je možné implementovať

atomické rozhrania pre synchronizáciu dát rôznych tabuliek/databáz

Možnosť prenosu iba pomerne nízkeho objemu dát. Zasielanie správ Pri definovaní vysokej

frekvencie zasielania správ je možné maximalizovať

včasnosť údajov

Možnosť prenosu iba nízkeho objemu dát.

Zdieľané biznis funkcionality Spúšťanie

vzdialených procedúr

Centralizácia funkčnosti a minimalizácia redundancie. Intuitívna implementácia (ako volanie lokálnych procedúr) Nutné implementovať transformačné komponenty medzi jednotlivými aplikáciami. Zasielanie správ Schopnosť transformácie

správ do definovaných formátov zabezpečuje prepojenie aplikácií cez voľnú väzbu

Väčšia

implementačná záťaž.

SOA architektúra Spúšťanie

vzdialených procedúr

Enkapsulácia

integrovaných aplikácií. (Každá aplikácia spravuje sama integritu svojich dát )

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. Zasielanie správ Jednotlivé systémy

vystupujú ako black-box so štandardizovaným popisom rozhraní dostupným v katalógu služieb Väčšia implementačná záťaž.

Distribuované biznis procesy Spúšťanie

vzdialených procedúr

Možnosť modelovania procesov už z existujúcich služieb, kde sa využíva iba volanie týchto služieb.

Nutné nasadiť platformu pre orchestráciu služieb; Implementácia transformačných komponentov Zasielanie správ Možnosť modelovania

procesov už z existujúcich služieb, kde sa využíva iba volanie týchto služieb.

Nutné nasadiť platformu pre orchestráciu služieb; Implementácia transformačných komponentov

Integrácia B2B Špecifický prípad

(20)

Metodika integrácie IS VS

20/51

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.

Princípy integrácie ISVS

3.1

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í Failure and Security

isolation

Poskytovanie funkčností vo forme webových služieb

Klastrovateľný aplikačný server

JAX-*, WS-*, WS-I. Popis služby 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,

(21)

Metodika integrácie IS VS

21/51

Požiadavka Tech. Požiadavka Štandardy

SOAP over HTTP Integrácia na ESB Aplikačný adaptér pre

príslušnú zbernicu (technológiu)

Životný cyklus IS musí podliehať riadenému životnému cyklu SOA služieb

Popis procesov pokrývaných vnútorne v IS BPMN, BPEL Releasovanie IS je identifikované aj na zmeny procesov a služieb

Integrácia používateľského rozhrania

Využívanie grafického rozhrania centrálneho portálu

Podľa výsledkov špecifikácie pre ÚPVS

Obalenie sluţieb Portletmi

WRSP 2.0 Podpora centrálneho

Identity managementu a SSO

3.1.1 Princípy integrácie na centrálne komponenty

Základné princípy integrácie ÚPVS:

• 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

3.2

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: Príklad:

Áno 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.

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

Ne aplikovateľné 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.

(22)

Metodika integrácie IS VS

22/51

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)

Imagem

Referências

temas relacionados :