Integračná architektúra

Transcription

1 Sprostredkovateľský orgán OPIS Riadiaci orgán OPIS Európska únia Integračná architektúra TVORÍME VEDOMOSTNÚ SPOLOČNOSŤ Európsky fond regionálneho rozvoja

2 Dokument Integračná architektúra bol vypracovaný pre Ministerstvo financií Slovenskej republiky dodávateľom KPMG Slovensko spol. s r.o. na základe zmluvy o poskytovaní poradenských služieb Štúdia uskutočniteľnosti projektov prioritnej osi 1 Elektronizácia verejnej správy a rozvoj elektronických služieb Operačného programu Informatizácia spoločnosti, zameranej na celkovú architektúru egovernmentu v rámci etapy Model implementácie - Metodický rámec pre projekty prioritnej osi 1 Elektronizácia verejnej správy a rozvoj elektronických služieb OPIS v roku Predmetný dokument upravilo Ministerstvo financií Slovenskej republiky v roku Autor: KPMG Slovensko spol. s r.o. Ministerstvo financií Slovenskej republiky

3 Obsah 1 Úvod 1 2 SOA platforma 3 3 Business Process Management 6 4 SOA Governance Určenie zodpovedností Implementácia riadenia Postup v rámci egovernment 10 5 Prvky SOA Enterprise Service Bus (ESB) Voľné prepojenie Transparentnosť pripojenia a umiestnenia Mediácia-sprostredkovanie Transformácia schémy Skladanie služieb Load Balancing Rozdeľovanie Záťaže Presadzovanie Bezpečnosti Monitorovanie Konfigurácia vs. Programovanie Service repository a Service registry Prvky BPM Business Process vrstva Web Service vrstva Rules vrstva SOA a BPM Zavedenie viacerých procesných manažérov Dôvody na zavedenie viacerých zberníc a BPM uzlov Zdôvodnenie decentralizovaného riešenia iných základných komponentov Požiadavky na zavedenie novej zbernice alebo BPM Portál 21 6 Štandardy WS-I Profily 22 7 Základné integračné požiadavky na ISVS 23 8 Súhrn základných požiadaviek a otvorené otázky Všeobecné požiadavky Požiadavky na ESB Požiadavky na Service repository a Service registry Požiadavky na BPM SOA Governance 24 A Zoznam použitých skratiek 25

4 B Podpora rozhodovania o vytváraní decentralizovaných riešení vybraných základných komponentov 26

5 1 Úvod Budovanie Informačného Systému Verejnej Správy (ISVS) je navrhnuté realizovať postupne a po častiach. Je to samozrejmé, nakoľko je ťažko predstaviteľné vybudovanie systému takéhoto rozsahu ako jeden veľký monolitický informačný systém. Riešenie ISVS ako množina samostatných informačných systémov prináša naopak iný problém a tým je integrácia týchto systémov do funkčného celku. Cieľom tohto dokumentu preto je: navrhnúť integračnú architektúru, opísať integračnú architektúru, identifikovať potrebné infraštruktúrne prvky, identifikovať, ktoré oblasti nie sú v súčasnosti pokryté. Dokument popisuje logický pohľad na integračnú architektúru. Nezaoberá sa a nepopisuje fyzickú vrstvu komunikačnú infraštruktúru, topológiu siete, konfiguráciu hardwarových uzlov a pod. V súčasnej dobe je ťažko predpokladať, že systémy budú realizované jediným dodávateľom alebo na jedinej technologickej platforme. Preto je nevyhnutné z pohľadu integrácie vyžadovať podporu a dodržiavanie technologických štandardov a mať možnosť používať filozofiu používania spoločných komponentov, resp. znovupoužitia niektorých komponentov. Z tohto dôvodu už Národná Koncepcia Informatizácie Verejnej Správy (NKIVS) predpokladala využitie integračnej vrstvy na báze servisne orientovanej architektúry (SOA) a táto metodika nebude na tom nič meniť. Servisne orientovanú architektúru je možné úspešne použiť na všetky tri typy integračných scenárov: integrácia na dátovej úrovni, integrácia na aplikačnej úrovni, integrácia na prezentačnej úrovni. Pri zavádzaní Servisne orientovanej architektúry sa vo všeobecnosti využívajú prístupy, ktoré môžeme rozdeliť nasledovne: Data Integration: umožňuje synchronizovať a konsolidovať aktuálne údaje obsiahnuté v mnohých produkčných systémoch za účelom zosúladenia týchto údajov a poskytuje master data management. Application Modernization: umožňuje modernizovať aplikácie a tzv. web-enabling zastaraných systémov (umožňuje použitie zastaraných systémov, ktoré sú v organizácii ako dedičstvo). Enterprise Integration (and Process management): umožňuje integrovať rôznorodé systémy za účelom zautomatizovania procesov. Composite Applications: umožňuje vybudovať aplikáciu, ktorá sprístupní naraz služby z viacerých a rôznorodých systémov, čím umožní ucelený (kombinovaný) pohľad na systémy. Stanovenie vhodnej architektúry je komplexný proces, môže viesť k nemu viacero ciest a môže existovať viacero správnych riešení. Bohužiaľ, neexistuje žiadny všeobecný návod pre riešenie integrácie v podnikoch alebo vo verejenej správe. Väčšina dostupných metodík a osvedčených postupov pochádza od spoločností, ktoré majú skôr tendenciu zameriavať sa viac na nástroje samotného predajcu a často im chýba širší pohľad vrátane základných pokynov, usmernení a osvedčených postupov. Keďže integrácia je vo svojej podstate zložitý proces, bolo rôznymi autormi vypracovaných niekoľko tzv. patternov (vzorov), ktoré v sebe zahŕňajú skúsenosti a poznatky z realizovaných riešení integrácie podnikových systémov. Zo širšieho pohľadu môžeme uviesť niekoľko základných patternov (vzorov), ktoré sú zamerané na najvšeobecnejšie SOA riešenia pre oblasti, kde sa predpokladá použitie viacerých komunikačných kanálov pri realizovaní biznis služieb. Jedná sa o organizácie s intenzívnou komunikáciou, ako sú napr. štátne organizácie, poisťovne a banky. Nasledovné všeobecné patterny popisujú problematiku SOA riešenia zo širšieho podnikového pohľadu: 1

6 Multi-Channel Bridging - Rieši problematiku spoločností a podnikov, ktoré pre výmenu informácií so svojimi zákazníkmi používajú viacero kanálov, napr. call centrum, internetový portál, telefón, písomnú korešpondenciu, atď. - Vyžaduje, aby sa používateľské vstupy spracovávali jednotne: proces by nemal byť závislý na zvolenom komunikačnom kanáli. - Umožňuje zachovať konzistenciu informácií a služieb naprieč komunikačnými kanálmi. - Vytvorenie mostu medzi komunikačnými kanálmi používateľov a skupinou zverejnených unifikovaných služieb. Business Process Composition - Umožňuje zachovať, resp. zvýšiť flexibilitu pri modifikovaní procesov organizácie, ktoré majú byť automatizované. - Definuje spôsob ako identifikovať a separovať tie biznis procesy, u ktorých sa predpokladá potreba neskorších zmien a modifikácií od tých, ktoré sú stabilné. - Definuje, že implementovanie procesných tokov je vlastne množina služieb, ktoré majú byť spustené sekvenčne podľa poradia stanoveného biznis procesom, t.j. ktoré sú orchestrované do uceleného biznis procesu. Orchestrácia znamená integrovanie nezávislých služieb. - Odporúča použitie vhodného externého nástroja na implementovanie orchestrácie. Enterprise Data Retrieval Services - Vhodné pre organizácie, ktoré potrebujú mať údaje v spoločne zdieľanej centrálnej databáze a je potrebné, aby boli vždy konzistentne použité naprieč všetkými obchodnými procesmi organizácie. - Umožňuje vytvoriť centrálny register, ktorý poskytne real-time prístup k jeho záznamom. - Umožňuje sprístupniť údaje, ktoré sú zdieľané naprieč celou organizáciou ako data retrieval služby. - Umožňuje zhlukovanie údajov tak, aby sa zabezpečila maximálne koherencia služieb. Replication In The Middle - Vhodné pre riešenia, pri ktorých je potrebné kombinovať údaje z viacerých registrov a systémov. - Replikovanie vybranej množiny údajov z viacerých zdrojov a ich umiestnenie do stredu organizácie medzi aplikácie a podnikové databázy. - Zabezpečuje konzistenciu zdrojových a replikovaných údajov. Composite Retrieval Services - Vhodné pre riešenia, pri ktorých je potrebné kombinovať údaje z viacerých registrov a systémov. - Umožňuje vytvoriť pohľady na údaje z viacerých zdrojov a skombinovať ich. Tieto pohľady môžu byť požadované a použité viacerými kompozitnými službami bez ohľadu na to, aký komunikačný kanál bol zvolený. - Umožňuje vytvoriť kombinované pohľady na údaje a zverejniť ich ako tzv. composite retrieval služby. Jednotlivé patterny je možné aplikovať samostatne, alebo je možné ich kombinovať, aby sa dosiahol požadovaný výsledok. Nesprávne použitie niektorého patternu môže mať naopak nežiaduci vplyv na výkonnosť a môže spôsobiť vážne problémy.

7 2 SOA platforma SOA integrácia založená na službách. Moderná integračná architektúra, ktorá ide presne opačným smerom, ako doterajšie integračné techniky a preferuje tzv. voľnú väzbu (loose coupling). Schéma základných stavebných blokov Servisne orientovanej architektúry je znázornená na nasledujúcom obrázku. Obrázok 1: Základné komponenty Servisne Orientovanej Architektúry 1 Základným východiskom je dôraz na minimálne množstvo informácií zdieľaných medzi aplikáciami, pričom zdieľanie interných implementačných záležitostí aplikácie (databázová schéma, obchodná logika, používateľské rozhranie) je prísne zakázané. Hnacím motorom konceptu SOA je XML a webové služby množina štandardov pre komunikáciu a výmenu údajov v heterogénnom prostredí. Koncept SOA dodržiava nasledovné charakteristiky: Minimálny zásah do existujúcej aplikácie: ak je pri implementácii vyžadovaný zásah do existujúcich aplikácií, mal by byť čo najmenší. Ak je zmena aplikácie nevyhnutná, mali by byť všetky zmeny lokalizované na jednom mieste. Nezávislosť a autonómia aplikácií: každá aplikácia by mala rešpektovať autonómiu ostatných aplikácií. Komunikácia medzi aplikáciami by mala prebiehať spôsobom, ktorý nevyžaduje žiadne znalosti internej funkcie druhej aplikácie. Nedostupnosť jednej aplikácie by mala mať minimálny dopad na funkciu celého systému, v ideálnom prípade by nemala zasiahnuť žiadnu inú aplikáciu (failure isolation), pričom s touto nedostupnosťou sa a priori počíta. Bezpečnostné zlyhania alebo prelomenie jednej aplikácie neohrozí ďalšie aplikácie (security isolation). Komunikácia medzi aplikáciami by mala byť natoľko všeobecná, aby mohla zostať zachovaná aj pri zmene alebo náhrade niektorej z aplikácií v ideálnom prípade by sa táto zmena alebo náhrada nemala mimo danej aplikácie vôbec prejaviť. Škálovateľnosť s počtom aplikácií: pridanie ďalšej aplikácie do integračného prostredia by malo pripomínať pripojenie typu Plug&Play. Zložitosť a nákladnosť tohto pripojenia by mali závisieť len na zložitosti 1 Dirk Krafzig, Karl Banke, Dirk Slama: Enterprise SOA: Service-Oriented Architecture Best Practices, Prentice Hall PTR,

8 a komplexnosti pripájanej aplikácie. Jednotlivé aplikácie je potom možné rozvíjať oddelene, bez ohľadu na zvyšok prostredia. Dodržiavanie štandardov: aplikácia by mala dodržiavať existujúce štandardy. Čím rôznorodejšie a heterogénnejšie prostredie, tým viac sa (dodržiavaním štandardov) integrácia zjednodušuje. K definovaniu zásad SOA napomáha referenčná architektúra SOA, ktorá poskytuje kľúčovú základňu. Reprezentuje architektonický rámec pre plánovanie projektov SOA, ktoré maximalizujú opätovné použitie služieb a definuje konzistenciu SOA. Jej koncepčnú úroveň reprezentuje nasledujúci obrázok. Obrázok 2: Konceptuálna schéma SOA Každý informačný systém ISVS bude musieť poskytovať svoje funkčnosti určené pre zdieľanie s inými systémami VS nielen vo svojej natívnej podobe (interné triedy a metódy prípadne procedúry a funkcie), ale zároveň vo forme webových služieb, ktoré spĺňajú súčasné technologické štandardy ako aj štandardy ISVS. Každý informačný systém potrebuje tieto webové služby mať sprístupňované vo forme aplikačného servera, resp. akéhosi service providera, webových služieb, ktoré daný IS poskytuje. To, ktoré služby budú IS povinné sprístupniť formou webových služieb by malo byť súčasťou zadania na príslušný informačný systém (IS), resp. právomocou Architektonického orgánu ISVS (ako súčasti riadenia programu výstavby ISVS) definovať pre príslušný systém služby, ktoré musí sprístupniť aj uvedeným spôsobom webových služieb.

9 Pre každý IS z ISVS to znamená, že musí mať niektoré služby zverejnené a musí byť pripravený v prípade vzniku požiadaviek sprístupniť aj iné, ktoré vykonáva. Systémy, ktoré nie sú postavené na webových službách môžu vyžadovať istú modifikáciu alebo doplnenie, aby mohli sprístupniť aj iné svoje funkcie. Ak informačný systém neposkytuje svoje funkčnosti vo forme služieb, tak je potrebné ich sprístupniť ako služby použitím štandardov a servisne orientovaných vývojárskych postupov. 5

10 3 Business Process Management Business Process Management (BPM) v servisne orientovanej architektúre predstavuje vrstvu, ktorá automatizuje biznis proces. Kombinuje role používateľov, biznis pravidlá a biznis aktivity služby do kompozície (tkz. orchestrácia služieb). BPM nástroje, umožňujú automatické spúšťanie jednotlivých služieb v stanovenom poradí (sekvenciách) tak, aby pokrývali celý definovaný biznis proces. BPM ako súčasť SOA referenčnej architektúry orchestráciou služieb vytvára zároveň integráciu nezávislých biznis aktivity služieb, ktoré obsahujú samostatnú a opakovane využiteľnú biznis logiku, spolu s riešením takých problémov ako sú čakanie na dočasne nedostupnú službu, náhrada transakcií (kompenzácie), čakanie na dlhotrvajúce transakcie a pod. Použitie prvku BPM vedie k vývoju hrubo granulovaných služieb v smere zhora nadol. Každá služba, ktorá bude vyvinutá týmto prístupom bude v podstate voľne zviazaná priamo s procesom. Tento prístup umožňuje to, aby biznis potreby diktovali smer vývoja jednotlivých služieb. Procesy je možné rozdeliť do štyroch základných kategórií: People oriented procesy,procesy s ľudskou interakciou Decision making procesy, rozhodovacie procesy Document management procesy, procesy správy a riadenia dokumentov a ich obsahu System integration-centric procesy. Procesy sústredené na systémy a ich integráciu Každý proces má svoj životný cyklus. Typické fázy sú: návrh resp. zachytenie procesu - proces je definovaný v grafickom nástroji s využitím grafickej notácie, napr. Business Process Modeling Notation (BPMN), XML Process Definition Language (XPDL). modelovanie alebo simulácia procesu, vykonávanie, beh procesu proces zapísaný vo forme Business Process Execution Language (BPEL) alebo, čo sú tzv. execution jazyky, monitorovanie procesu, business activity monitoring (BAM) zlepšenie procesu výstup z monitorovania procesu je vstupom pre zlepšenie procesu. Na BPM engine bežia jednotlivé inštancie procesov, na ktorých je možné vykonávať monitoring a auditing, ako napríklad: dĺžku trvania procesu, počet priebehov jednotlivých procesov, ktorý používateľ vykonal koľko úloh. BPM zavádza aj koncept pravidiel (business rules). Tie určujú, kam sú jednotlivé činnosti v procese smerované, ktorá úloha bude vykonaná ako ďalšia a ako dlho môže proces čakať na reakciu systému alebo človeka. Pravidlá tvoria rozhodnutia v bežiacom procese. Pravidlá sú definované vlastníkom procesu v modelovacej fáze. Business Rules Engine (BRE) umožní vlastníkovi procesu meniť pravidlá v procese bez modifikovania definície procesu a následného generovania novej verzie aplikácie. Popísaním procesu prostredníctvom napr. BPEL jazyka umožníme spúšťanie jeho inštancií na BPM engine, monitoring týchto inštancií a presné dodržiavanie jednotlivých krokov procesu. V prípade, že dôjde k zmene procesu, tak je možné ho verzionovať s tým, že BPM engine zabezpečí dobehnutie už existujúcich inštancií daného procesu podľa starej verzie a štartovanie nových inštancií podľa novej verzie (napr. sa do procesu pridá nový krok nutnosť overenia nedoplatkov voči štátnej inštitúcii a pod.) V prípade, že informačný systém podporuje, resp. pokrýva nejaké ucelené alebo čiastkové procesy, tak musí byť popísaný použitím BPEL. BPEL (Business Processing Execution Language) je priemyselným štandardom orchestrácie, centrálne koordinovaného skladania diskrétnych aplikačných služieb (definovaných cez štandard webových služieb) do kompozície procesného toku. Procesný tok obsahuje väzby na heterogénne systémy, synchrónny a asynchrónny messaging, dátovú manipuláciu, rozhodovanie a koordináciu, správu výnimiek a nedeterministických udalostí, transakcie, verzionovanie, správu a audit. Je to nový štandard, ktorý zúročuje viac ako štrnásťročné skúsenosti vývoja v tejto oblasti.

11 4 SOA Governance Cieľom SOA dozoru (governance) je zaručiť, že zvolená SOA stratégia prinesie spoločnosti alebo organizácii maximálnu hodnotu. Je to stanovenie kontroly, riadenia a administrácie IT prostredia za účelom ovplyvňovania a presadzovanie definovaných akcií a chovania. Úplne základnou aktivitou tohto dozoru je manažment životného cyklu SOA služieb. Pomocou troch procesov riadenie portfólia služieb, využívanie služieb a vytváranie služieb, sa riadi plánovanie, definícia, vývoj a použitie služieb. Riadenie životného cyklu SOA služieb sa tak snaží zaručiť, že každá služba má čo najvyššiu možnú kvalitu, je používaná správne a že sa buduje správne portfólio služieb, ktoré poskytuje najvyššiu možnú hodnotu. SOA Governance adresuje - Aké rozhodnutie musia byť urobené pre efektívnu správu? Kto musí tieto rozhodnutia urobiť a kto ma aké práva? Ako bude rozhodnutie formulované? Efektívna SOA Governance je kombinácia ľudí, procesov a technológii. Adresuje celkový SOA životný cyklus (od vytvárania cez použitie a zosúladenie so zámermi organizácie) Ďalšie aktivity, ktoré môžeme zahrnúť pod SOA Governance je Service Policy management vrstva a Service Level management vrstva. Service Policy management zabezpečuje dodržiavanie bezpečnosti a vynucovanie politík pre webové služby. Zvyčajne sa jedná o aplikáciu bezpečnosti na úrovni správ bez kódovania, aplikáciu prístupových pravidiel, aplikáciu transformácií a smerovacích politík, systematické vyžadovanie politík počas prevádzky a v neposlednom rade aj správu politík. Service Level management zabezpečuje monitorovanie odoziev a dostupnosti webových služieb. Pri tejto funkcii ide najmä o získavanie kľúčových metrík, monitorovania procesov, nastavenia upozornení na výnimky správu cieľových SLA služieb. Riadenie SOA je potrebné navrhnúť tak, aby umožňovalo organizáciám využívať plný potenciál architektúry SOA. Najzávažnejšie problémy obklopujúce otázky životného cyklu služieb sú: rozhodovacie práva kto má oprávnenie rozhodovať a v ktorých otázkach, merania a kontroly ako zistiť, či boli ciele dosiahnuté. Efektívne riadenie je viac ako len technológia. Vyžaduje si prístup so zreteľom na životný cyklus, do ktorého budú začlenení ľudia a procesy organizácie a informácie a základné prostriedky riadenia SOA. Rámec riadenia SOA: stanovenie rozhodovacích práv pre prostredie SOA, definovanie vhodných služieb, riadenie životného cyklu prostriedkov služieb, posúdenie účinnosti. Rámec je odrazom porozumenia cieľov a plánov organizácie, čo povedie k rozhodovaniu akú podobu bude mať SOA referenčná architektúra a aké investície sú potrebné. Akonáhle bude toto hotové, rámec riadenia SOA určí potrebné procesy, role a aké technológie sa využijú. Výsledkom bude agilný, efektívny a vyhodnotiteľný rámec, ktorý pomôže realizovat výhody SOA prístupu. Pre úspešnosť implementácie SOA je potrebné riadenie SOA Governance vytvoriť už v úvodnej fáze procesu. Služby SOA vyžadujú zlepšené riadenie, aby bola zachovaná úroveň kontroly, ktorá je potrebná na podporu nového spojeného IT prostredia. K hodnotám, ktoré riadenie SOA poskytuje, patria: Využívanie prínosov architektúry SOA - zabezpečuje flexibilitu procesov, - umožňuje zlepšovať čas uvedenia produktov na trh, 7

12 - zníženie komplexnosti (eliminácia redundancie, optimalizácia opätovného požitia) - zviditeľnenie a podpora analýzy vznikajúcich SOA-IT aktív. Znižovanie rizika - pomáha udržiavať kvalitu, - zaručuje konzistentnosť, - zosúladenie (s referenčnou architektúrou, s projektovými požiadavkami) Efektivita IT tímov - meranie správnosti IT metrík, - zlepšuje komunikáciu IT. Zvyčajne pre SOA Governance sú potrebné dve úrovne tzv. Mikro a Makro. Kým mikro je zmeraná priamo na služby, makro je orientovaná na vytváranie správnych modulov podľa definovanej architektúry ak ich vzájomný súlad v životnom cykle. Ucelený životný cyklus vyžaduje využitie nástroja pre SOA Asset Management: Jediný zdroj pravdy pre SOA portfólio, Správa SOA assetu/projektov a príslušných metadát, Sledovanie závislostí a analýzy vplyvu, Automatizácia zberu assetu a metadát z rôznych zdrojov, Poskytuje runtime referenceie pre pripojenie a politiky, Poskytuje štruktúru a automatizáciu SOA životného cyklu, Sleduje využitie a súlad pre zobrazenie v ROI. Riadenie pravidiel-politík a rozširovania: Centralizovná správa politík artefaktov pre verzovanie a riadenie zmeny, Distribuované rozširovanie do SOA infraštruktúry, Umožňuje kontinuálne vyhodnocovanie design-time politík, Zaistí súlad s politikou prostredníctvom životného cyklu, Umožňuje priamu kontrolu riadenia životného cyklu. Správa konzumentov: Poskytuje štruktúrovaný kontrakt medzi konzumentom a poskytovateľom, Umožňuje definovať podmienky využitia na báze politík, Vyžaduje kontrakty cez biznis, SLA a bezpečnostné politiky, Poskytuje bázu pre zdieľaný servisný model. SOA Monitorovanie a Administrácia: Centrálna správa distribuovanej a heterogénnej SOA, Vizualizácia end-to-end servisnej siete, Monitorovanie, diagnostika a zaistenie servisnej úrovne, Sledovanie využívania servisných kontraktov, Sledovanie kvality služby QoS, Pokrýva metriky a analýzu potrebnú pre rozhodovanie. 4.1 Určenie zodpovedností Role v organizácii IT musia byť úplne pochopené a starostlivo monitorované. Zásadné úlohy riadenia sú zobrazené na nasledujúcom obrázku. Medzi hlavné oblasti riadenia patria: Strategické zoskupenie (Strategic alignment) sa zameriava na potrebu zladiť vízie, ciele a potreby s IT snahami.

13 Cena dodávky (Value delivery) sa zameriava na to, ako sa hodnota IT preukáže prostredníctvom výsledkov, ako je zníženie nákladov, zníženie chýb, a tak ďalej. Riadenie rizík (Risk management) sa zameriava na zachovanie kontinuity činností a aby boli prijaté opatrenia k ochrane majetku IT. Riadenie zdrojov (Resource management) sa zameriava na optimalizáciu infraštruktúry služieb, ktoré sú súčasťou On Demand Operating Environment alebo iné prostredie podporujúce aplikačné služby. Riadenie výkonnosti (Performance management) sa zameriava predovšetkým na monitorovanie služieb, ktoré pracujú v podnikovom On Demand Operating Environment alebo v inom prostredí. Nasledujúci model znázorňuje päť hlavných súvisiacich IT rozhodnutí, ktorými možno riešiť vyššie uvedené oblasti riadenia. Obrázok 3: Model súvisiacich IT rozhodnutí. Obrázok zachytáva rôzne prvky riadenia a ich vzťahy. Všeobecne môžeme konštatovať, že IT a SOA princípy (IT and SOA principles), ktoré sú umiestnené na riadiacej úrovni organizácie riadia IT architektúru a model služieb (IT architecture and the service model), ktorý zase riadi IT infraštruktúru (IT infrastructure) v organizácii, ako môže byť definovaná. Hodnotenie potrieb Required business application môžu byť založené na spôsobilosti IT infraštruktúry. Vyzretosť IT architektúry, modelu služieb a IT infraštruktúry určuje, ktoré časti z required business application môže byť prioritné pre IT investície (IT investment). 4.2 Implementácia riadenia Riadenie by malo byť sústredené na štyri piliere architektúry: ľudia, procesy, technológie a služby. Implementácia riadenia musí byť podporovaná hierarchickou, organizačnou štruktúrou hlásení. Ako ukazuje obrázok, takéto hlásenia je možné rozdeliť do štyroch hierarchických úrovní. Na nasledujúcom obrázku je znázornený model pre správu organizačnej štruktúry: 9

14 Obrázok 4: Hierarchické úrovne riadenia. Sponzorská úroveň (Sponsorship level). Pozostáva zo zúčastnených strán v rámci riadiaceho výboru, ktorý je zastúpený vedúcimi pracovníkmi. Riadiaci výbor definuje stratégiu, ciele a vízie. Členovia tejto úrovne majú kľúčové rozhodovacie právomoci na to, ako IT investičné potreby realizovať a napájať na špecifické oblasti podnikania, ďalej zlepšovať proces, alebo implementovať nové aplikácie, ktoré môžu byť konkurencieschopné na trhu. Vedenie (Leadership level). To pozostáva z vodcu (prípadne vodcov) a dvoch zástupcov z každej oblasti. Vedenie získava informácie o stratégiách a víziách od sponzorov, zo smerníc a zo správ riadiaceho výboru. Vedenie tímu vytvára IT architektúru a SOA princípy, ktoré stoja nad pravidlami a ktorým sa podriaďuje architektúra aplikácií. Tím stanovuje priority, ktorú aplikačnú architektúru je potrebné vytvoriť a zaručuje že IT priority sú zosúladené s potrebami. Manažment príležitostí (Opportunity management level). Oddelené tímy sú tvorené na tejto úrovni, z ktorých každý sa zameriava na jednu alebo viac potrieb a sú zodpovedné za jasnú definíciou aplikácií. Úroveň projektového riadenia (Project Management level). Tímy na tejto úrovni riadia celý životný cyklus aplikačného dizajnu a vývoja prostredníctvom definovaných etáp riešenia, ako sú analýza, dizajn, realizácia, testovanie a nasadenie. Implementácia riadenia v technickom prevedení zvyčajne využíva úlohovo orientovaný proces tzv. (human workflow, pracovný postup), ktorý býva súčasťou technickej realizácie SOA Governance prostredia nazývaného aj service repozitory. 4.3 Postup v rámci egovernment V úvodnej fáze je potrebné identifikovať procesy najvyššej úrovne, ktoré má štátna správa a samospráva v rámci egovernmentu zabezpečovať. Proces by mal byť stotožnený konkrétnou službou egov (resp. prostredníctvom nej so životnou situáciou občana alebo podnikateľa a s príslušným úsekom správy a jeho agendou). Treba si uvedomiť, že proces je súslednosť činností v istom poradí. Ak sú jednotlivé činnosti nezávislé, tak ide o samostatné procesy. Po identifikácií základných procesov musí dôjsť k ich dekompozícii na subprocesy a nakoniec až na atomické kroky služby IS. Tieto činnosti sú vykonávané v rámci štúdií realizovateľnosti.

15 Pri popise procesov sa ukazuje, že mnoho z nich pozostáva z krokov, ktoré sa v procesoch často opakujú. Majú spoločné jednotlivé kroky resp. akési jadro, ktoré je popísané ako generický model egov služby. Generický model egov služby predstavuje šablónu na tvorbu procesov v jednotlivých doménach (napr. ministerstvá). Takto identifikované procesy spolu s jednotlivými službami a vzájomnými väzbami budú zviditeľné v service repozitory, kde bude prebiehať SOA governance proces. Identifikované procesy treba popísať jazykom BPMN. Spôsob modelovania procesov popisuje samostatný dokument Modelovanie procesov. Jednotlivé kroky procesov predstavujú identifikované služby IS a ľudskú interakciu podľa príslušnej role. Vstupné a výstupné podmienky formulujú parametre služby IS. Je potrebné identifikovať opakujúce sa služby IS a zabrániť tomu, aby sa opakovane neimplementovali. Keďže viaceré kroky nie sú pokryté, navrhujeme zaviesť kanceláriu architekta egov, ktorá bude pokrývať tieto činnosti. Bude rozhodovať o zavedení nového procesu, služby IS, popisu procesu vo formáte BPMN, identifikácii duplicít služby IS a pod. Základné rámce organizácie riadenia sú uvedené v dokumente Programové riadenie na úrovni životného cyklu služieb egovernmentu. Podporným nástrojom pre členov kancelárie bude Metainformačný systém (jeho časť Service Repository). Povinná osoba, ktorá sa rozhodne zaviesť samostatný BPM pre vybrané procesy, musí zabezpečiť popis týchto procesov v BPMN a pokiaľ sa jedná orchestračné procesy aj v BPEL a ich následné nasadenie a implementáciu v rámci BPM uzla. 11

16 5 Prvky SOA 5.1 Enterprise Service Bus (ESB) ESB ako jeden zo základných stavebných prvkov servisne orientovanej integrácie umožní prejsť postupne na servisne orientovanú architektúru a využiť možnosti tejto konfigurovateľnej integračnej vrstvy. Koncept ESB prináša voľnú väzbu aj na operácie a metódy aplikácií, ktoré spolu s dátami vytvárajú služby, ESB: sprostredkúva komunikáciu medzi službami (integrovanými aplikáciami) prostredníctvom správ, ESB zabezpečuje prenos správ, spoľahlivé doručenie správ, transformáciu správ a ich smerovanie, Umožňuje komunikáciu buď synchrónnym spôsobom request reply alebo asynchrónnym spôsobom publish subscribe. Zavedenie zbernice oproti riešeniu bez použitia zbernice (point-to-point prepojenia) prináša množstvo výhod pri riešení nasledovných úloh: verzionovanie služieb, spoľahlivé doručovanie správ, virtualizácia služby, riadenie a vynucovanie bezpečnostných politík, monitorovanie služieb, autentifikácia a autorizácia, šifrovanie, digitálne podpisovanie, transformácia správ, routovanie správ. Moderné ESB musia riešiť nasledovné oblasti: Voľné prepojenie Voľné spojenie nie je dosiahnuté s WSDL alebo webovou službou samostatne. Robustnejšie riešenie je dosiahnuté využitím sprostredkovacej vrstvy medzi klientmi a poskytovateľmi služieb. Takáto sprostredkovacia vrstva by mala byť tiež schopná premostiť protokoly, formáty správ a zabezpečovacie technológie. Napríklad služba by mohla byť zavolaná prostredníctvom tradičného mechanizmu HTTP protokolu, ale to potom môže vyvolať protokol inej nižšej úrovne služieb napríklad prostredníctvom Java Message Service (JMS), , File Transfer Protocol (FTP), a tak ďalej. Tento prístup je často efektívny a používa sa pri "zabalení" starších služieb a ich prenosových protokolov k novším klientom služieb Transparentnosť pripojenia a umiestnenia Transparentnosť pripojenia je stratégia ukrývania fyzického umiestnenia koncových bodov služby pre klientov služby. V ideálnom prípade klienti služieb by mali vedieť o jedinom, logickom stroji a mene portu pre každú službu. Klient by nemal poznať skutočné koncové body služby. To umožňuje väčšiu flexibilitu pri správe služieb. Potom je možné pridať, premiestniť a odstrániť koncové body služby podľa potreby, bez toho aby bolo potrebné prekompilovať klientov služby Mediácia-sprostredkovanie ESB je medzi vrstva, ktorá je umiestnená práve medzi klientmi a poskytovateľmi služieb. Táto vrstva poskytuje výborné miesto pre zvyšovanie pridanej hodnoty pre architektúru, bez toho, aby sa zmenili aplikácie na oboch koncoch.

17 ESB je vlastne poskytovateľom služby pre klientov služby. Pri používaní služieb ESB klientmi služieb, ESB má schopnosť vykonať niekoľko operácií: môže transformovať dáta alebo schémy správ, ktoré vysiela a prijíma, s inteligentne smerovať správy na rôznych poskytovateľov služby a to v závislosti od obsahu týchto správ Transformácia schémy Webové služby, ktoré sú publikovné na servisnej zbernici môžu využiť inú schému ako je pôvodná schéma poskytovateľa služby, ktorého reprezentujú. To je zásadná schopnosť, najmä pri použití v spojení s kanonickou taxonómiou alebo pri agregácii a orchestrácii iných webových služieb. Je to pomerne časté, že klient služby bude musieť prijímať svoje údaje pomocou schémy, ktorá je značne odlišná od poskytovateľa služieb. Schopnosť transformovať dáta z jednej schémy na inú je rozhodujúcou vlastnosťou pre úspech akejkoľvek ESB platformy Skladanie služieb ESB môže pôsobiť ako fasáda a vykonáva rad volaní webových služieb, ktoré sa objavujú klientovi ako jediná služba. Skladanie služieb využíva tento model, ktorý volá viac volaní služieb v mene tzv. proxy služby a vracia jediný výsledok späť klientovi. Servisná orchestrácia je podobná agregácii služieb kde navyše objavujú niektoré atribúty podmienkovej logiky, ktorá definuje aké z nižšej úrovne služieb sú volané a v akom poradí. ESB umožňuje implementovať známy objektový pattern, ktorý preferuje kompozíciu objektov, v tomto prípade služieb, pred rigidným dedením objektov, resp. služieb Load Balancing Rozdeľovanie Záťaže Vzhľadom k umiestneniu v akejkoľvek architektúre, ESBs sa dobre hodí na rozloženie záťaže požiadaviek na viacej koncových bodov služby. Pri registrácii poskytovateľa služby je zvyčajne možné zadať zoznam koncových bodov služby kde je služba spustená. Je možné zmeniť tento zoznam, pridať alebo odobrať koncový bod služby, bez nutnosti reštartovať ESB server Presadzovanie Bezpečnosti Bezpečnosť by sa mala presadzovať centralizovaným spôsobom, kedykoľvek je to možné. Toto umožní vyššiu úroveň štandardizácie a kontroly v bezpečnostných otázkach. Ďalej bezpečnosť je najlepšie presadzovaná pomocou frameworku, ktorý je riadený politikami. Použitie bezpečnostnej politiky znamená, že vytvorenie a uplatňovanie bezpečnostných štandardov sa deje mimo tvorby individuálnych služieb Monitorovanie ESB hrá samozrejme dôležitú úlohu pre zavedenie SOA. Preto je potrebné mať silný spôsob sledovania stavu prevádzky na ESB a to v aktívnom a aj reaktívnom režime. Schopnosť aktívneho zobrazenia výkonnostných ukazovateľov na ESB môže pomôcť vyladiť výkon ESB. Monitorovanie výkonnosti môže ďalej pomôcť plánovaniu zvýšenia kapacity. Reaktívne monitorovanie umožňuje nastaviť upozornenia na konkrétne podmienky a situácie. Napríklad, ak konkrétna služba nie je vykonaná rámci definovaného času, ESB by malo mať možnosť poslať upozornenie tak, že administrátor môže začať analyzovať dôvody problému Konfigurácia vs. Programovanie Moderné rišenie ESB by malo byť konfiguračne-založené, nie závislé od programovania. Tu neexistuje nič na kompilovanie a nasadzovanie. Jednoducho sa zmení konfigurácia a aktivujú sa tieto zmeny. Podobne ako napríklad 13

18 aj telefón je konfiguračne - založený zvolíte telefónne číslo, ktoré chcete volať a hovor je následne vytvorený. Nie je potrebný reštart telefónu. Podobne, sieťové smerovače a prepínače sú konfiguračne založené. Ako sa vytvoria zmeny v konfigurácii tieto sa uvedú do platnosti. Pre ESB teda zvyčajne nie je potrebný dlhý životný cyklus vývoja softvéru. Každý informačný systém si môžeme predstaviť ako poskytovateľa služieb a používateľa služieb iných informačných systémov. Potom situáciu môžeme logicky znázorniť takto: Obrázok 5: Základná schéma ESB Mimo zbernice vznikne aj nový uzol: Service registry, čo je Universal Description Discovery and Integration register (UDDI register) runtime časť katalógu služieb. Z pohľadu informačných systémov verejnej správy je ideálne, keď poskytujú aplikačný adaptér (konektor) pre vybranú zbernicu. V prípade, že pre vybranú zbernicu neexistuje aplikačný adaptér, je možné pripojiť sa technologickým adaptérom (konektorom).

19 Obrázok 6: Možnosti pripojenia na ESB Uvedený model predstavujú ideálny stav, keď všetky služby sú ľahko dosiahnuteľné, sú na jednom mieste. Toto ale nie je prípad služieb v rámci egovermentu. V rámci egovernmentu rozlišujeme služby (a informačné systémy) na centrálnej úrovni a samosprávnej úrovni. Informačné strediská samospráv sú rozmiestnené v jednotlivých mestách a obciach, a je prakticky nepredstaviteľné, že by poskytovali služby odtiaľ. Preto aj v zmysle odporúčania z dokumentu Národná Koncepcia rozvoja informatizácie verejnej správy odporúčame vybudovať špecializované Dátové centrum obcí a miest (DCOM). V tomto prípade bude architektúra vyzerať nasledovne: Obrázok 7: Pripojenie DCOM Partner Zone predstavuje DCOM a Enterprise Secure Zone predstavuje Dátové Centrum štátnej správy. Zelenou farbou sú označené samosprávne služby (informačné systémy). 5.2 Service repository a Service registry Service repository predstavuje katalóg informácií o jednotlivých službách od ich návrhu, vývoja, testovania až po ich nasadenie. Obsahuje SOA artefakty ako WSDL (Web Service Definition Language) popisy, XSD (XML Schema Definition) schémy, požiadavky, procesné modely, pravidlá a štandardy, SLA (Service Level Agreement) a politiky služieb, metriky, verzie a pod. Okrem Service repository existuje aj Service Registry register služieb, ktorý slúži na publikovanie a vyhľadávanie služieb, obsahuje definície služieb, popis ich rozhrania, operácií a parametrov. Service repository predstavuje v podstate rozšírenie registra služieb, pretože sa snaží udržiavať všetky artefakty, ktoré v rámci SOA vznikajú. Implementácie jednotlivých výrobcov sa ale líšia. Tieto dva prvky infraštruktúry môžu byť vybudované: buď ako dva samostatné systémy, alebo postavené na Service Registry, ktorý je rozšírený o ďalšie SOA artefakty, alebo ako Service repository systém, ktorý v sebe obsahuje Service Registry. Jednotlivé informačné systémy VS by mali svoje služby popísať a vložiť do Service repository. 5.3 Prvky BPM Proces si môžeme predstaviť ako procesný tok, ktorý sa skladá zo sekvencie vyvolania služieb. Proces je kontrolovaný centrálne, prostredníctvom Procesného manažéra a nie je súčasťou programovej logiky v jednotlivých aplikáciách. Preto je možné ho modelovať a implementovať centrálne. Jednoducho to môžeme znázorniť takto: 15

20 Obrázok 8: Základné prvky riešenia BPM Ak spravíme dekompozíciu na nižšiu úroveň, situácia bude vyzerať takto: Obrázok 9: Dekompozícia prvkov riešenia BPM Business Process vrstva Táto vrstva je zodpovedná za správu a výkon všetkých obchodných procesov. Tie, implementované cez BPEL, môžu byť dlhodobo bežiace, transakčné, perzistentné. BPEL vrstva podporuje audit a nástroje workflowu a preto je vhodná na: Separáciu viac stálych workflow krokov od nestálych biznis pravidiel, Implementáciu line-of-business procesov, Implementáciu procesných tokov vyžadujúcich kompenzáciu,

21 Podporu vysoko škálovateľného vytvárania inštancií procesných tokov, Dizajn procesných tokov vyžadujúcich auditing, Orchestráciu heterogénnych technológií ako sú konektory, Web služby a Web Services Invocation Framework (WSIF) logika Web Service vrstva Vystavuje existujúcu aplikačnú funkcionalitu ako službu. Viaceré biznis procesy ich tak môžu opakovane využívať a tak napĺňať prísľub SOA. Web služby implementujú funkcionálnu a doménovú logiku. Funkcionálne metódy sú typicky bezstavové a stredne granulované (napr. služba Vytvor účet, Vytvor report). Web služby môžu obsahovať úžitkové metódy, operácie s entitami, vyhľadávacie metódy v systémových dátach. Implementované môžu byť rôznymi technológiami a ukrývať rozdiely medzi implementačnými platformami. Táto vrstva je vhodná na: Implementovanie stredne granulovaných metód pre čiastkové entity/domain oblasti, Integrovanie starého kódu/treťostranných nástrojov, Zabalenie logiky, zákazkového kódu a implementáciu z aplikačnej vrstvy Rules vrstva Typicky býva doménou komplexnej logiky, ktorá zahŕňa množstvo závislostí medzi entitami a logickými kalkuláciami. Extrakcia biznis pravidiel z procesov vedie k voľnej väzbe medzi systémemi, čo je žiadúcim prvkom v komplexnej architektúre z pohľadú údržby a správy. Vyhodnocovanie pravidiel v rules engine je možné uskutočnovať v paralelnom alebo sekvenčnom usporiadaní. Pravidlá sú deklaratívne a moderné rules engines poskytujú vysokoúrovňové grafické rozhrania pre analytikov na ich vytváranie a editáciu. Poskytujú tiež audit logging a vysoký výkon spracovania pravidiel implementovaný v efektívnych algoritmoch. V rules engines bývajú pravidlá vystavené ako Web služby, takže môžu byť využívané rôznymi aplikáciami a vytvárať priestor pre jednoduchšiu integráciu. Ako bolo spomínané vyššie, pravidlá typicky modelujú zložitú návratovú štruktúru, ktorá vyžaduje viaceré biznis validácie a politiky, ktoré sa často môžu meniť na rozdiel od procesov organizácie modelovaných v business process vrstve. Typický vývoj pravidiel v procesoch zahŕňa vytvorenie pravidiel a ich skupín, ich vystavenie ako Web služby a volanie cez BPEL. 5.4 SOA a BPM BPM je možné prevádzkovať samostatne, ale predstavuje prirodzený doplnok k servisne orientovanej architektúre, resp. druhú stranu mince SOA, ktorá vystavuje IT funkcionalitu ako biznis aktivity služby. Z pohľadu servisne orientovanej architektúry je BPM informačný systém, ktorý poskytuje služby (spustenie procesu, zistenie aktuálneho stavu procesu,...) ako aj naopak používa služby iných informačných systémov (vyvoláva tie služby, z ktorých sa daný proces skladá). Z tohto pohľadu je možné ho napojiť na zbernicu podobne ako iné systémy, ktoré poskytujú/používajú služby: Po dekompozícii zbernice a Business Process Management (BPM ) dostávame nasledovný model: 17

22 Obrázok 10: Dekompozícia riešenia pripojenia BPM na ESB Je dôležité všimnúť si, že bez použitia zbernice (pozri časť 5.3) musel mať Process Manager spojenie na všetky služby, ktoré potrebuje v rámci procesu vyvolať (služby, z ktorých je daný proces zložený). Teraz je potrebné len pripojenie na zbernicu. Navyše je takto proces v BPM odolný voči implementačným zmenám volanej služby spočívajúcej napríklad v pridaní nových IT zdrojov, alebo ich presunov. Nakoniec pre podmienky egovernment bude spojená architektúra vyzerať nasledovne: Obrázok 11: Spojená architektúra egovernmentu Nové prvky v tejto architektúre, a to ESB, ESB Adapters a BPM Process Manager a Rules Engine ) odporúčame vybudovať v rámci samostatného projektu integračnej infraštruktúry NKVISZavedenie viacerých zberníc Najlepšia stratégia pri návrhu počtu zberníc je mať len JEDNU zbernicu. Existuje ale viacero dôvodov, kedy je potrebné zaviesť viac než jednu zbernicu. V prípade, že interakcia medzi samosprávnymi službami navzájom je vysoká a zároveň interakcia medzi samosprávnymi službami a centrálnymi službami je nízka, tak v tom prípade môže postačovať slabšie rýchlostné prepojenie medzi centrami a vtedy je vhodné zaviesť samostatnú zbernicu pre služby IS samosprávy. V tom prípade by architektúra vyzerala nasledovne:

23 Obrázok 12: Samostatné ESB pre samosprávy Dôvodom na zavedenie ďalšej zbernice môže byť rozhodnutie o zriadení samostatného Dátového centra pre samosprávne kraje, oddelene od Centra obcí a miest. V tom prípade by architektúra vyzerala takto: Obrázok 13: Zavedenie samostatného dátového centra v rámci samosprávy Okrem zberníc pre každé centrum pribudla medzidoménová zbernica, pretože v prípade, že treba prepojiť viac ako dve zbernice, tak toto je vo väčšine prípadov vhodnejší model ako priame prepojenia zberníc navzájom. 5.5 Zavedenie viacerých procesných manažérov Dôvodom na zavedenie samostatného procesného manažéra pre samosprávu je napr. existencia viacerých procesov, ktorých vlastníkom je samospráva a tieto procesy sa skladajú zo služieb, ktoré sú všetky (alebo väčšina) poskytované alebo volané v rámci informačných systémov samosprávy. 5.6 Dôvody na zavedenie viacerých zberníc a BPM uzlov Existuje viacero dôvodov, či už technických alebo organizačných, na zavedenie ďalších zberníc a BPM uzlov. Všetky uvedené dôvody sú taktické, strategicky je najlepšie riešenie mať jednu zbernicu. Poznámka: V každom prípade je však potrebné zachovať možnosť riadenia a monitorovania celého riešenia egovernmentu z jedného miesta, t.j. vybrať jednu zbernicu, ktorá bude mať z hľadiska SOA Governance privilegovanú úlohu. Zrejme sa bude jednať o zbernicu, ku ktorej bude pripojený tzv. Metainformačný systém (pozri tiež časť 5.2, 8.1 a 8.3). 19

24 Dôvody na zavedenie viacerých ESB, BPM v rámci jednej organizácie, resp. v rámci egov sú nasledovné: Viacero riadiacich (governance) orgánov: Existencia viacerých riadiacich orgánov často vedie k zavedeniu viacerých ESB a BPM. Z pohľadu riadenia integračného riešenia je často priechodnejšie implementovať viac ESB a BPM, ktoré sú prispôsobené pre potreby daných riadiacich štruktúr, než navrhnúť a implementovať spoločné riešenie. Každý riadiaci orgán má svoju zónu vplyvu, v rámci ktorej kontroluje aj architektúru a implementáciu prvkov infraštruktúry (ESB a BPM nevynímajúc). Modely financovania: spôsob, akým spoločnosť financuje projekty môže tiež viesť k existencii viacerých ESB, BPM. Ak spoločnosť nemá centrálne financovanie, tak ESB, BPM implementácie budú rozkúskované a rozpojené. Napríklad, ak je financovanie integračných technológií na projektovej úrovni, tak si každý projektový tím môže navrhnúť a inštalovať ESB, BPM ako súčasť projektu. Toto samozrejme nie je ideálny spôsob financovania a ani návrhu a implementácie integračných technológií. Vedie to k premnoženiu ESB a BPM, ktoré sú upravené na špecifické potreby daných projektov. Prispôsobenie pre danú organizačnú jednotku: rôzne organizačné jednotky resp. inštitúcie môžu mať špecifické integračné požiadavky. Napr. jedna organizačná jednotka môže potrebovať, aby použitá technológia bola certifikovaná špecifickým certifikátom, zatiaľ čo iné to nevyžadujú, alebo vyžadujú iné typy certifikácií. V takých prípadoch môže byť časovo a cenovo výhodnejšie zaviesť viacero ESB, BPM ako postaviť jednu, ktorá by bola prispôsobená na všetky možné požiadavky všetkých organizačných jednotiek. Geografické ohraničenie: niekedy je praktickejšie zaviesť pre každú lokalitu samostatnú ESB, BPM, obzvlášť v prípade, keď rýchlosť, bezpečnosť a spoľahlivosť prepojenia medzi nimi je nízka. Viaceré technológie: technológia použitá dodávateľom ESB, BPM nemusí byť interoperabilná s technológiami od dodávateľov jednotlivých IS. Mnoho aplikačných modulov je bundlovaných s už konkrétnou ESB technológiou. Ich vytrhnutie a reimplementácia vedie k zvýšeniu ceny a nutnosti opätovného testovania. V niektorých prípadoch zas spoločnosť nechce byť závislá od jedného dodávateľa a radšej zavedie viacero rôznych technológií, ktoré sú medzi sebou interoperabilné Zdôvodnenie decentralizovaného riešenia iných základných komponentov Spôsob a dôvody pre decentralizáciu zberníc ESB a bodov BPM, ktoré sú popísaný v kapitole 5.6, sú aplikovateľné aj na decentralizáciu riešení vybraných základných komponentov. Na základe týchto dôvodov sa bude architekt egovernment riešenia rozhodovať o prípadoch samostatného (t.j. decentralizovaného) riešenia vybraných základných komponentov. Okrem riešenia ESB a bodov BPM prichádza do úvahy decentralizácia nasledovných komponentov: modul centrálnej elektronickej podateľne (CEP), modul eform, modul dlhodobého ukladania registratúrnych záznamov (MDURZ). Na vyjadrenie / rozhodnutie takéhoto osamostatnenia môže byt použitá šablóna podľa prílohy B. 5.7 Požiadavky na zavedenie novej zbernice alebo BPM V prípade, že povinná osoba má akceptovateľný dôvod na zavedenie novej zbernice, musí táto spĺňať požiadavku bezproblémového prepojenia s už zavedenými zbernicami. V prípade, že povinná osoba má akceptovateľný dôvod na zavedenie nového BPM uzla, tak musí spĺňať požiadavku na bezproblémové reportovanie všetkých procesov pre potreby centrálneho monitoringu v tom istom formáte, v akom budú reportovať už zavedené BPM uzly.

25 Povinná osoba musí novú zbernicu navrhnúť a implementovať takým spôsobom, aby bolo možné využiť výhody zbernicového riešenia, ktoré sú zhrnuté v bodoch v časti Portál Sprístupnenie funkčností jednotlivých systémov pre používateľa sa v servisne orientovanej architektúre rieši prostredníctvom tzv. portálu. Portál predstavuje centralizovaný bod prístupu, ktorý umožňuje volať funkčnosti z rôznych informačných systémov cez jednotné používateľské rozhranie. Používateľ často ani nevie o existencii týchto backend informačných systémov. Portál je ďalší prvok nevyhnutný pre SOA infraštruktúru, ktorý je potrebné vybudovať. Tento však bude riešený v rámci definície prvku architektúry Ústredný Portál Verejnej Správy a Portál zamestnancov verejnej správy. Na to, aby portál dokázal volať funkčnosti jednotlivých IS, musia byť tieto prístupné vo forme webových služieb. V tomto prípade ale samotné grafické rozhranie musí byť vybudované na portáli. Jedným s príkladov takéhoto prístupu je použitie elektronických formulárov. Vtedy portál umožňuje editáciu a prehliadanie XML dokumentov a komunikuje prostredníctvom webových služieb. Portál poskytuje rôzne prvky na vybudovanie používateľského rozhrania nad týmito formulármi rôzne pohľady podľa typu akcie (iný pohľad pre novú žiadosť, iný pre schvaľovanie), samotné ovládacie prvky, umožňuje podmienené formátovanie, obmedzenie vstupných hodnôt, vyvolanie akcií pri zadaní konkrétnej hodnoty a pod. Kontrola správnosti údajov sa väčšinou kontroluje zadefinovaním presnej XSD schémy pre daný formulár. Vzniknutý XML dokument vlastne predstavuje správu, ktorá sa zasiela vybranej webovej službe, prípadne priamo na integračnú zbernicu. Ďalšou možnosťou, ktorú je potrebné ponechať je, že informačné systémy dodajú funkčnosti spolu aj s grafickým rozhraním tzv. portlety. V tom prípade portál vznikne jednoduchým poskladaním takýchto portletov do celku. Portlety musia podporovať WSRP protokol, najlepšie najnovšiu verziu 2.0. Portlet komunikuje so svojou backend aplikáciou a tá reaguje na vzniknuté udalosti komunikáciou s integračnou zbernicou. 21

26 6 Štandardy V ďalšom vymenujeme štandardy, ktoré sa používajú pri servisne orientovanej architektúre. Okrem štandardov existujú aj tzv. Web Services Interoperability (WS-I) Profily, ktoré poskytujú implementačné odporúčania, ako by sa mali súvisiace Web Services (WS) špecifikácie (štandardy) spolu používať pre čo najlepšiu interoperabilitu. Pri budovaní jednotlivých prvkov SOA infraštruktúry a pri integrácii systémov ISVS je nutné, aby tieto štandardy a profily boli podporované. Komunikačné protokoly: HTTP 1.1, HTTPS, plus messaging protokol: JMS alebo iný, Správy formát a protokoly: SOAP 1.1/SOAP 1.2, XML 1.0, MTOM/XOP, SOAP with Attachments, REST Identity, Location: WS-Addressing 1.0, Kvalita služby (bezpečnosť, spoľahlivosť): WS-Security 1.1, WS-ReliableMessaging 1.1, WS- SecureConversiation 1.3, WS-Trust, WS-Federation, Definícia služieb, metadáta: WSDL 1.1, XSD, WS-Policy, WS-MetadadaExchange, UDDI 3.0, Business Process Management: BPMN, XPDL, WS-BPEL 1.1/WS-BPEL 2.0, WS-BPEL extension for People, Používateľské rozhranie: WSRP WS-I Profily Jednotlivé WS-I profily obsahujú vybranú množinu WS štandardov plus popis spoločného používania týchto štandardov. Jeden WS-I Profil môže byť postavený na inom WS-I Profile. WS-I Basic Profile, WS-I Attachments Profile, WS-I Simple SOAP Binding Profile, WS-I Basic Security Profile, WS-I Reliable Secure Profile.

27 7 Základné integračné požiadavky na ISVS Zhrnutie základných filozofických a prípadných technických požiadaviek na ISVS, aby ich bolo možné integrovať podľa konceptu SOA. P.č. Požiadavka Tech. požiadavka Štandardy 1 Autonómnosť aplikácií Failure and Security isolation 2 Poskytovanie funkčností vo forme webových služieb 3 Životný cyklus IS musí podliehať riadenému životnému cyklu SOA služieb 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 Integrácia na ESB Popis procesov pokrývaných vnútorne v IS Releasovanie IS je identifikované aj na zmeny procesov a služieb 4 Integrácia používateľského rozhrania Využívanie grafického rozhrania centrálneho portálu Výmena správ niektorými štandardnými protokolmi ako JMS, HTTP, SOAP over JMS, SOAP over HTTP Aplikačný adaptér pre príslušnú zbernicu (technológiu) BPMN, BPEL Obalenie služieb Portletmi WRSP 2.0 Podpora centrálneho Identity managementu a SSO Podľa výsledkov špecifikácie pre ÚPVS 23