1F44C/008/030. Roční zpráva. Část 2 ze dvou částí Dodatky

Transkript

1 WAK-1F44C WAK System Název projektu: Automatizovaná výměna dat mezi informačními systémy krizového řízení v dopravě s jednotným univerzálním a implementovaným rozhraním založeným na standardu webových služeb Číslo projektu: 1F44C/008/030 Název zprávy: Roční zpráva Název části: Část 2 ze dvou částí Dodatky Období: Poskytovatel: Příjemce: Adresa příjemce Odpovědný řešitel: Spoluřešitelé: Ministerstvo dopravy ČR WAK System, spol. s r.o. Petržílkova 2564/21, Praha 5 - Stodůlky Ing. Radan Kasal Ing. Luděk Benda Ing. Tomáš Nagy Ing. Petr Půlpán Radek Valeš RNDr. Miroslav Wasserbauer Ing. Vítězslav Života Datum vydání:

2

3 Dodatek A. - Analýza domény IS A.1 Shromážděné podklady k doméně Pro řešení jsme vycházeli jak z dostupné literatury, tak z materiálů dostupných na internetu. Vycházelo se také z příslušných legislativních norem. Výstupem analýzy podkladů dle bodů A.1.2 a A.1.4 jsou rešerše popsané dále v odstavcích A a A A.1.1 Literatura k doméně Shromážděnou literaturu k doméně jsme rozdělili do dvou kategorií: UML a UP Vývojové a implementační platformy V následujících odstavcích uvádíme jejich seznam. A UML a UP V kategorii UML a UP byla nalezena a použita následující literatura: Ivar Jacobson, Grady Booch, James Rumbaugh The unified software development process [4] Joseph Smuller Myslíme v jazyku UML [5] Jim Arlow, Ila Neustadt UML a unifikovaný proces vývoje aplikací [6] A Vývojové a implementační platformy V kategorii vývojových a implementačních platforem byla nalezena a použita následující literatura: Jeffrey Richter.NET Framework programování aplikací [7] Dino Esposito XML Efektivní programování pro.net [8] Dalibor Kačmář Programujeme.NET aplikace [9] A.1.2 Legislativa k doméně V doméně byly nalezeny a prozkoumány následující legislativní normy: Zákon 239/2000 Sb. o integrovaném záchranném systému [10] WAK-1F44C Str. 1

4 Zákon 240/2000 Sb. o krizovém řízení (krizový zákon) [11] Zákon 241/2001 Sb. o hospodářských opatřeních pro krizové stavy [12] A.1.3 Standardy k doméně V oblasti standardů k doméně se vycházelo z dokumentů W3C ( Web Services Architecture [13] Web Services Architecture Requirements [14] Web Services Glossary [15] Web Services Architecture Usage Scenarios [16] Web Service Management: Service Life Cycle [17] SOAP Version 1.2 Part 0: Primer [18] SOAP Version 1.2 Part 1: Messaging Framework [19] SOAP Version 1.2 Part 2: Adjuncts [20] SOAP Version 1.2 Specification Assertions and Test Collection [21] SOAP Version 1.2 Message Normalization (Note) [22] A.1.4 Krizové informační systémy V oblasti krizových informačních systému se vycházelo z dokumentů ke krizovému informačnímu systému KIS MDS, obzvláště pak z následující příručky: Krizový informační systém KIS MDS Systémová příručka [23] A.1.5 Rešerše vybraných podkladů A Krizové plánování V oblasti státní správy a samosprávy existují informační systémy (dále IS) pro zabezpečení požadavků zákona 240/2000 sb. o krizovém řízení (krizový zákon). Paragraf 26 tohoto zákona hovoří o požadavcích na tyto IS. IS mají splňovat standardy informačních systémů státní správy a dále se na IS klade mimo jiné požadavek technického a programového přizpůsobení pro činnost v obtížných podmínkách. Jak vyplývá ze zákona 240/2000 Sb., krizové plány zpracovávají: Ministerstva a jiné správní úřady. WAK-1F44C Str. 2

5 ČNB. Kraje. Obecní úřady. Kancelář PS PČR, Kancelář Senátu, KPR, Úřad vlády, NKÚ a BIS. Krizový plán se skládá ze základní a přílohové části. Základní část krizového plánu obsahuje: Charakteristiku organizace krizového řízení. Vymezení působnosti, odpovědnosti a úkolů zpracovatele krizového plánu. Výčet a hodnocení možných rizik, jejich dopad na území a činnost subjektů krizového plánování. Další podklady a zásady potřebné pro používání přílohové části krizového plánu. Následující diagram popisuje základní části krizového plánu: od Analýza KP - Základní část KrizovýInformačníSystém * ZákladníČást KrizovýPlán PřílohováČást CharakteristikaOrganizaceKrizovéhoŘízení + CharakteristikaOdbornýchČinnostíProKrizovéŠtáby: + OrganizačníSchémaSložekProKritickouInfrastrukturu: + OrganizačníStrukturaZpracovatele: + PředpokládanéZměnyOrganizačníStrukturyZaKrizovýchStavů: + Schéma organizace krizového řízení: + SeznamOsobKteréSePodílelyNaZpracováníKrizovéhoPlánu: + VariantyOrganizačníchStrukturKrizovéhoŠtábu: PůsobnostOdpov ědnostúkolyzpracovatele + NázevAdresaZpracovatele: + PřehledZpracovatelůPřílohKrizovéhoPlánu: + SpojeníNaOperačníAInformačníStřediska: + SpojeníNaZpracovatele: + VymezeníOdpovědnostiZpracovateleJehoPůsobnost: + VymezeníÚzemníPůsobnostiZpracovatele: 1 KrizováRizika + DůsledkyMožnýchKrizovýchRizik: + VýčetMožnýchKrizovýchRizik: DalšíPodkladyZásady + PřehledKrizovéASouvisejícíLegislativy: + FormulářeProVyhlášeníKrizovýchStavůDalšíSouvisejícíDokumenty : + MetodikyScénářePomůckyProPráciKrizovýchŠtábů: + VzorovéFormulářeNaUkládáníPracovníVýpomoci: + StatutJednacíŘádKrizovéhoŠtábu: + SměrniceProManipulaciSNeutajovanýmiZvláštnímiAUtajovanýmiSkutečnostmi: + VzoryAFormulářeDokumentaceProRozhodováníAProváděníŘídícíchOpatření: + VzorovéFormulářePovinnostiPoskytnoutVěcnýProstředek: + VzoryDokumentaceSpisovéSlužbyKrizovéhoŠtábu: + ZásadyManipulaceSKrizovýmPlánemZpůsobJehoAktualizace: Obr. A.1.1 Analýza krizového plánu základní část Přílohová část krizového plánu obsahuje dokumenty nutné pro zvládnutí krizové situace, zejména: WAK-1F44C Str. 3

6 Přehled sil a prostředků, jejich počet a využitelnost. Katalog krizových opatření obsahující zásady a postup realizace krizových opatření. Typové plány. Operační plány. Povodňové a havarijní plány. Plán nezbytných dodávek. Plán hospodářské mobilizace. Plán akceschopnosti zpracovatele KP. Plány spojení, materiálně technického a zdravotnického zabezpečení a topografické mapy s vyznačenými riziky a řešením ohrožení. Následující diagram zobrazuje třídy přílohové části krizového plánu: cd Analýza KP - Přílohová část KrizovýInformačníSystém * ZákladníČást KrizovýPlán PřílohováČást PlánNezbytnýchDodávek PřehledNezbytnýchDodávek: + PřehledDodavatelůNezbytnýchDodávek: PřehledSilAProstředků + PřehledVyužitelnýchSil: + PřehledVyužitelnýchVěcnýchProstředků: + PřehledVyužitelnýchSlužeb: + KontaktyProVyžádáníSil: + KontaktyProVyžádáníVěcnýchProstředků: + KontaktyProVyžádáníSlužeb: PlánAkceschopnosti PlánHospodářskéMobilizace KatalogKrizovýchOpatření TypovýPlán OperačníPlán + HavarijníPlány: + OperačníPlánProZajištěníÚkolůObrany: + OperačníPlányProJednotlivéDruhyOhrožení: + VnějšíHavarijníPlány: 1 * * + PostupyProVyrozuměníSvoláníKrizovéhoŠtábu: + PřehledPracovišťKrizovýchŠtábů: + ReakceZpracovateleNaVyhlášenJednotlivýchKrizovýchStavů: + DalšíOpatřeníNutnáKZajištěníAkceschopnostiZpracovatele: + OpatřeníProOchranuOsobPracovišťKrizovéhoŠtábu: + OpatřeníProZprovozněníAOchranuZáložníhoNeboChráněnéhoPracoviště: + SeznamOsobVKrizovýchŠtábech: DalšíPlán - PlánySpojení: - PlánMateriálněTechnickéhoZabezpečení: - PlánZdravotnickéhoZabezpečení: - MapyRizikAŘešení: Obr. A.1.2 Analýza krizového plánu přílohová část Jak vyplývá z 15 zákona 240/2000, hasičský záchranný sbor kraje je oprávněn za účelem přípravy na krizové situace vyžadovat, shromažďovat a evidovat údaje o: WAK-1F44C Str. 4

7 kapacitách zdravotnických, ubytovacích a stravovacích zařízení, předmětu a rozsahu činnosti právnických osob a podnikajících fyzických osob v oblasti výroby a služeb, výrobních programech a výrobních kapacitách, rozsahu zásob surovin, polotovarů a hotových výrobků, počtech zaměstnanců a jejich kvalifikaci, počtech zaměstnanců ve výrobních provozech a počtech osob bydlících v místech předpokládané evakuace, množství, složení a umístění vyráběných, používaných nebo skladovaných nebezpečných látek, množství zadržené vody ve vodních nádržích, počtech a typech dopravních, mechanizačních a výrobních prostředků ve vlastnictví právnických nebo fyzických osob a druzích vyrobené nebo zachycené přírodní energie, uspořádání vnitřních prostorů výrobních objektů, popřípadě jiných objektů důležitých pro řešení krizových situací, vodovodech, kanalizacích, produktovodech a energetických sítích, stavbách určených k ochraně obyvatelstva při krizových situacích, k zabezpečení záchranných prací, ke skladování materiálu civilní ochrany a k ochraně a ukrytí obsluh důležitých provozů, výměrách pěstovaných zemědělských plodin a druhu a počtu zemědělských zvířat chovaných právnickými nebo fyzickými osobami pokud tyto údaje jsou nezbytné pro zpracování krizových plánů pro přípravu a řešení krizových situací. Jak vyplývá z 26 téhož zákona, orgány krizového řízení při plánování krizových opatření a při řešení krizových situací využívají informační systémy krizového řízení. Tyto musí splňovat standardy informačních systémů veřejné správy a pravidla: přenosu informací nadřízeným, podřízeným a spolupracujícím orgánům krizového řízení, technického a programového přizpůsobení pro činnost v obtížných podmínkách, bezpečnosti uchovávaných informací stanovené pro informace s nejvyšším stupněm utajení obsažené ve zpracované dokumentaci. Orgány krizového řízení při plánování krizových opatření odpovídají za dodržení zásady rovnocennosti písemných a elektronických údajů obsažených v krizovém plánu. Zákon 239/2000 o integrovaném záchranném systému vymezuje integrovaný záchranný systém, stanoví složky integrovaného záchranného systému a jejich působnost. Dále stanovuje působnost a pravomoc státních orgánů a orgánů územních samosprávných celků, práva a povinnosti právnických a fyzických osob při přípravě na mimořádné události a při krizových stavech. WAK-1F44C Str. 5

8 Zákon 241/2000 upravuje přípravu hospodářských opatření pro stav nebezpečí, nouzový stav, stav ohrožení státu a válečný stav - krizové stavy a přijetí hospodářských opatření po vyhlášení krizových stavů. Tento zákon stanoví pravomoc vlády a správních úřadů při přípravě a přijetí hospodářských opatření pro krizové stavy. Stanoví též práva a povinnosti fyzických a právnických osob při přípravě a přijetí hospodářských opatření pro krizové stavy. Metodika zpracování krizových plánů dle 15 a 16 nařízení vlády č. 462/2000 Sb. ve znění nařízení vlády č. 36/2003 Sb. stanovuje postup při zpracování krizového plánu ministerstva, jiného správního úřadu, České národní banky a jiného státního orgánu (dále jen krizový plán správního úřadu ) a krizového plánu územního samosprávného celku pro řešení krizových situací nesouvisejících se zajišťováním obrany České republiky před vnějším napadením. A Webové služby V současné době je velice dobře přijímána a široce implementována technologie webových služeb. Jedná se o standard pro komunikaci mezi různými softwarovými aplikacemi na různých platformách prostřednictvím síťových služeb. Formát zpráv je založen na technologii XML dokumentů. Webová služba využívá pro popis svého rozhraní schéma WSDL vyjádřené dokumentem XML a pro vlastní přenos zpráv se využívá protokol SOAP, rovněž založený na XML. Popisy standardu webových služeb jsou obsaženy v dokumentech World Wide Web konsorcia (dále W3C). W3C navrhuje infrastrukturu pro webové služby, definuje potřebné standardy a klíčové technologie. V rámci W3C jsou vytvořeny pracovní skupiny, které se zabývají jednotlivými aspekty technologie WS. Jsou to: Pracovní skupina pro architekturu webových služeb. Tato skupina publikuje dokumenty, zabývající se spojením dílčích technologií do celku fungující webové služby. Pracovní skupina pro XML protokol (SOAP framework). Jejím úkolem je definovat systém pro výměnu zpráv založený na protokolu XML. Pracovní skupina pro adresování ve webových službách. Tato skupina navrhuje standardy pro vkládání adresovacích informací do zpráv přenášených pomocí webových služeb. Pracovní skupina pro popis webových služeb. Tato skupina navrhla jazyk pro popis rozhraní WS WSDL (Web Service Description Language). Pracovní skupina pro interakci webových služeb (Web Services Choreography). Tato nedávno založená skupina definuje standard pro definici vztahů mezi WS a výměnu zpráv mezi WS. Vytváří definici jazyka pro popis peer-to-peer spolupráce mezi agenty WS Web Services Choreography Description Language (WS CDL). Na následujícím diagramu jsou přehledně znázorněny technologie webových služeb: WAK-1F44C Str. 6

9 cd Technologie WS TechnologieWebovýchSlužeb SpolupráceWebovýchSlužeb / WS-CDL PopisWebovýchSlužeb / WSDL SystémZpráv / SOAP, adresování Obr. A.1.3 Technologie webových služeb Z dokumentů publikovaných skupinou pro architekturu webových služeb je klíčový dokument Web Services Architecture. Tento dokument definuje komponenty webové služby a vztahy mezi nimi. Dalším dokumentem je Web Services Architecture Requirements, který znovu definuje webovou službu a určuje úkoly pro pracovní skupiny W3C. Dokument Web Services Glossary přehledně definuje termíny používané v dokumentu Web Services Architecture a v problematice Webových služeb obecně. Dokument Web Services Architecture Usage Scenarios obsahuje diagramy případů užití Webových služeb a sekvenční diagramy komunikace mezi WS a klientem služby. Následují krátké rešerše těchto dokumentů: A Dokument Web Services Architecture Dokument definuje webovou službu jako softwarový systém vytvořený k zajištění spolupráce mezi různými softwarovými aplikacemi provozovanými na různých platformách. Webová služba má normalizované rozhraní popsané strojově zpracovatelným jazykem (WSDL). Aplikace komunikují s webovou službou pomocí zpráv protokolu SOAP založeném na XML. Webová služba je abstraktním pojmem, který je implementován agentem konkrétním hardwarovým a softwarovým systémem, který vysílá a přijímá zprávy, zatímco webová služba jako taková je charakterizována funkcionalitou, kterou poskytuje. Dokument popisuje základní scénář fungování webové služby. Scénář je založený na následujících pojmech: Provider strana, která poskytuje WS (server). Provider Agent hardware a software na straně serveru (agent serveru). Requester strana, která požaduje WS (klient). WAK-1F44C Str. 7

10 Requester Agent - hardware a software na straně klienta (agent klienta). Web Service Description (WSD) definice formátů zpráv, datových typů, transportních protokolů a způsobu serializace přenosu. K popisu je použit WSDL (Web Service Description Language). Sémantika WS definuje chování služby jako reakci na zasílané zprávy klienta. Pro zápis sémantiky WS není v tomto dokumentu žádné doporučení. Pro zprovoznění komunikace mezi serverem a klientem na bázi webových služeb jsou obecně zapotřebí 4 fáze: 1. Seznámení serveru a klienta. 2. Server a klient se dohodnou na popisu a sémantice webové služby. 3. Popis a sémantika je implementována agentem serveru a agentem klienta. 4. Agent serveru a agent klienta komunikují a si vyměňují zprávy. Seznámením serveru a klienta se rozumí získání adresy klienta serveru za předpokladu, že iniciátorem komunikace je klient typická situace. Toho lze dosáhnout přímo, nebo pomocí systému Web Service Discovery. Dohodou na popisu a sémantice se nerozumí jen možnost přímé komunikace mezi serverem a klientem, vedoucí k dohodě. Popis webové služby může být pevně dán WSDL a sémantika popsána další dokumentací na straně serveru, který předpokládá, že ji klient bez výhrad přijme a implementuje. Popis a sémantika webové služby může být také předepsána průmyslovým standardem, nebo jinou normou, která je závazná pro stranu klienta a serveru. Další možností je definice popisu a sémantiky služby na straně klienta. Popis i sémantika webové služby mohou být na straně agenta serveru i na straně agenta klienta implementovány různě napevno dány kódem software agenta, nebo určeny parametricky. Agent serveru si s agentem klienta vyměňují zprávy založené na SOAP (Simple Object Access Protocol). Dále se dokument zabývá problematikou Seznámení serveru a klienta. Popisuje mechanismus Web Service Discovery, který se používá v případě, že agent klienta požaduje vyhledání agenta serveru, který poskytuje definované služby. Pro tento proces je zapotřebí kromě popisu služby (WSD) ještě funkční popis (FD). Jedná se o strojově zpracovatelný popis funkcionality a do jisté míry i sémantiky služby. Dokument rozebírá možnosti fungování discovery service pro vyhledání požadované webové služby na základě funkčního popisu, případně jiných kritérií. A Dokument Web Services Architecture Requirements Dokument definuje webovou službu jako softwarový systém definovaný pomocí URI (adresa, uniform resource identifier dle RFC 2396), jehož veřejná rozhraní a vazby jsou definovány pomocí XML. Tyto definice mohou být získávány pomocí jiných softwarových systémů. Tyto systémy pak mohou spolupracovat s WS způsobem daným touto definicí s využitím zpráv založených na XML zasílaných pomocí protokolů Internetu. WAK-1F44C Str. 8

11 A Dokument Web Services Architecture Usage Scenarios Dokument ve formě use case diagramů a sekvenčních diagramů obsahuje příklady použití webových služeb. Příklady jsou doplněny vzory příslušných SOAP zpráv. Následuje typický diagram zobrazující nejjednodušší formu SOAP komunikace jednosměrnou komunikaci klienta a serveru, kdy klient nevyžaduje žádnou odpověď. cd Scénář použití - pouze dotaz SOAP Klient SOAP Server Aplikač ní vrstva SOAP aplikace klienta :SOAP aplikace SOAP aplikace serveru :SOAP aplikace SOAP vrstva SOAP procesor klienta :SOAP procesor 1: SOAP dotaz SOAP procesor serveru :SOAP procesor Síťová vrstva (operační systém) Síťové rozhraní klienta :Síťové rozhraní Síťová komunikace Síťové rozhraní serveru :Síťové rozhraní Obr. A.1.4 Scénář použití webové služby pouze dotaz Tento model může mít variantu, kdy je SOAP zpráva zasílána více serverům pomocí nějaké formy síťového broadcastu, nebo postupným voláním dle seznamu adres serverů. Další variantou je model, kdy server vrací klientovi nějakou odpověď. Může se jednat například o návratový kód volání. Diagram popisující takovou situaci je obdobný: cd Scénář použití - dotaz a odpověď SOAP Klient SOAP Server Aplikač ní vrstva SOAP aplikace klienta :SOAP aplikace SOAP aplikace serveru :SOAP aplikace SOAP vrstva SOAP procesor klienta :SOAP procesor 1: SOAP dotaz 1.1: SOAP odpověď SOAP procesor serveru :SOAP procesor Síťová vrstva (operační systém) Síťové rozhraní klienta :Síťové rozhraní Síťová komunikace Síťové rozhraní serveru :Síťové rozhraní Obr. A.1.5 Scénář použití webové služby dotaz a odpověď WAK-1F44C Str. 9

12 Scénáře počítají i s možností, kdy transportní protokol nepodporuje synchronizaci mezi požadavkem a odpovědí. V takovém případě se musí o tuto synchronizaci postarat SOAP aplikace s využitím SOAP hlaviček. Volající SOAP aplikace přidává do SOAP hlavičky požadavku jedinečné ID zprávy a server toto ID využije při generování odpovědi. Diagram dotaz a odpověď se rozpadá na dva diagramy pouze dotaz. Dalším popisovaným scénářem je případ, kdy volání SOAP serveru obsahuje sadu RPC volání a návratová zpráva obsahuje návratové hodnoty z RPC. Z následujícího diagramu je vidět, že SOAP aplikace zprostředkovává RPC volání. cd Scénář použití - RPC SOAP vysílač SOAP přijímač SOAP aplikace klienta : SOAP aplikace SOAP aplikace serveru : SOAP aplikace Aplikač ní vrstva RPC požadavek klienta SOAP tělo RPC požadavek serveru RPC odpověď klienta SOAP tělo RPC odpověď serveru SOAP vrstva SOAP procesor klienta :SOAP procesor 1: SOAP dotaz 1.1: SOAP odpověď SOAP procesor serveru :SOAP procesor Síťová vrstva (operač ní systém) Síťové rozhraní klienta :Síťové rozhraní Síťová komunikace Síťové rozhraní serveru :Síťové rozhraní Obr. A.1.6 Scénář použití webové služby RPC Tento diagram předpokládá, že transportní protokol podporuje synchronizaci mezi požadavkem a odpovědí. Pokud tomu tak není, je třeba využít pro udržení korelace mezi požadavkem a odpovědí ID zpráv vložené do SOAP hlaviček. A Dokument Web Services Management:Service life cycle Tento dokument popisuje životní cyklus webové služby, která je implementována konkrétním agentem. Popisuje stavy do kterých se může webová služba dostat během svého životního cyklu a přechody mezi nimi. WAK-1F44C Str. 10

13 Základní životní cyklus webové služby, kdy služba po počáteční inicializaci přechází do aktivního stavu, kdy je schopna přijímat požadavky a ze kterého může přecházet do pasivního stavu a zpět a nakonec svůj běh ukončit, popisuje následující diagram: ad Životní cyklus Aktivní Inicializace Aktivace Agent akceptuje požadavky Start Deaktivace Ukončení Stop Pasivní Agent neakceptuje požadavky Obr. A.1.6 Životní cyklus webové služby Jestliže je agent aktivní, může se nacházet v podstavu Busy obsluhuje klienta, nebo v podstavu Idle neobsluhuje žádný požadavek. Ze stavu Start služba přechází obvykle do podstavu Idle. Přímo do podstavu Busy může přejít, pokud přechází ze saturovaného podstavu v rámi pasivního stavu. Diagram aktivního stavu je na následujícím obrázku. ad Aktivní stav Busy Agent vyřizuje požadavek Uvolnění / Zotavení Start Stop Idle Agent je v klidovém stavu Obr. A.1.7 Životní cyklus webové služby - aktivní stav Jestliže je agent ve stavu Pasivní, může se nacházet v podstavu Zastaven, Saturován, nebo Havárie. Každý tento podstav může být v rámci stavu konečný, případně je možný WAK-1F44C Str. 11

14 přechod z podstavu Saturován do stavu zastaven nebo opuštění podstavu Pasivní po uvolnění zdrojů. Stejně tak může služba po havárii opustit stav Pasivní a svoji činnost ukončit, nebo může přejít do administračním zásahem do podstavu Zastaven. Přechody mezi podstavy v rámci stavu Pasivní jsou na následujícím diagramu: ad Pasivní stav Zastaveno Agent webové služby byl zastaven Start Počet požadavků na agenta webové služby přesáhl limitní počet Saturováno Restart Administrač ní zásah Uvolnění zdrojů Havárie Obnovení činnosti Stop Při provozu došlo k havárii agenta Obr. A.1.8 Životní cyklus webové služby pasivní stav A Dokument SOAP Version 1.2 Primer Tento dokument popisuje vlastnosti protokolu SOAP jako protokolu založený na XML, který dovoluje přenos strukturované typově ohodnocené informace mezi uzly v distribuovaném prostředí. Základní schéma SOAP zprávy je následující: WAK-1F44C Str. 12

15 cd SOAP_Reprezentace Blok_SOAP_Hlavičky SOAP_Hlavička SOAP_Obálka * 1 1 Blok_SOAP_Těla SOAP_Tělo 1 1..* Obr. A.1.9 SOAP reprezentace SOAP zpráva se skládá z hlavičky a těla. Hlavička zprávy je volitelná a může obsahovat data, která nemají přímý vztah k aplikaci. V XML hlavičkách se například dají přenášejí data, která mají vztah ke zpracování zprávy. Tělo zprávy je povinné a obsahuje vlastní informace zprávy. Dále dokument vysvětluje mechanismus SOAP RPC, kdy je v SOAP zprávě zapouzdřeno volání procedury systému na straně serveru. Uvádí příklad takové SOAP zprávy. Dokument se také zabývá otázkou řešení chybových stavů při zpracování SOAP zprávy. Oznámení chyby je řešeno zvláštními poli v hlavičce zprávy. Dále je v dokumentu řešena vazba protokolu SOAP na protokol HTTP. Ukazuje použití metod SOAP HTTP GET a SOAP HTTP POST. A Dokument SOAP Version 1.2 Messaging Framework Dokument zpracovává následující témata: Zpracování SOAP zpráv. Rozšíření SOAP Vlastnosti a moduly SOAP. Napojení na protokol nižší vrstvy pravidla pro napojení na protokol, který bude použit pro výměnu SOAP zpráv mezi uzly. Strukturu SOAP zpráv. Dokument popisuje elementy SOAP zprávy Obálky (element SOAP Envelope), hlavičky (element SOAP Header) a těla (element SOAP Body). Dokument dále popisuje použití URI (Uniform resource identifier jednotný identifikátor zdroje) v SOAP protokolu. A Dokument SOAP Version 1.2 Part 2: Adjuncts Dokument se zabývá následujícími tématy: WAK-1F44C Str. 13

16 Datový model SOAP Kódování SOAP RPC reprezentace SOAP SOAP konvence pro vlastnosti a napojení Vzory pro SOAP výměnu zpráv Vazba SOAP na HTTP Datový model SOAP reprezentuje aplikačně závislé datové struktury jako orientovaný ohodnocený graf. Účelem je spojitá reprezentace dat, která nejsou ve formátu XML. Jedná se o volitelnou vlastnost,. kterou není nutné použít, pokud jsou data ve formátu XML. Kódování SOAP nabízí způsob kódování dat, která odpovídají datovému modelu SOAP. Účelem RPC reprezentace SOAP je umožnit přenos zpráv, které reprezentují volání procedur a metod. Dokument se zabývá identifikací RPC zdrojů v prostředí WWW a vkládáním RPC volání do kontextu SOAP dokumentu. A Dokument SOAP Version 1.2 Specification Assertions and Test Collection Dokument obsahuje seznam podmínek a testů, kterým musí vyhovovat implementace SOAP procesoru pro verzi SOAP 1.2. Pro tyto testy rovněž definuje vstupní podmínky a obsah SOAP zpráv, které si uzly v rámci testů vyměňují. A Dokument SOAP Version 1.2 Message Normalization Dokument definuje transformační algoritmus, kterým lze přeložit na identický vzor všechny sémanticky ekvivalentní SOAP zprávy. Tento algoritmus může být použit pro generování otisků SOAP zpráv, které jsou odolné proti transformaci zprávy jdoucí přes zprostředkovatelské servery. Tato normalizace může být využita pro aplikaci digitálních podpisů v XML. A Krizový informační systém KIS MDS A Stručný popis systému KIS je softwarový databázový produkt pro podporu procesů krizového řízení. Je vytvořen v souladu s ustanoveními zákona o krizovém řízení č.240/2000 Sb. a jeho prováděcími předpisy. Všechny údaje krizového plánu se uchovávají v databázi (MS Access, MS SQL Server nebo Oracle). KIS umožňuje generovat dokumenty krizových plánů do formátu MS WORD a vybraná data importovat nebo exportovat z a do formátu MS EXCEL. KIS disponuje prostředky pro obecnou časovou analýzu jednotlivých úkolů a jejich vazeb, jak pro část plánování krizových situací, tak pro řešení krizových situací, založenou na metodě CPM. Sleduje kapacitní nároky a aktuální stavy sil a prostředků a to jak jejich okamžité, tak kumulativní hodnoty. WAK-1F44C Str. 14

17 KIS podporuje zpracování geografických informací podle standardu ESRI Shapefile. K jednotlivým datovým objektům je možné přiřadit a zobrazit geografické údaje. Ty je možné nadále přenášet do jiných uzlů pomocí standardních exportních souborů systému. Grafické zobrazení dat je možné uložit do souborů typu SHP nebo BMP. KIS umožňuje přenášet data mezi jednotlivými uživateli systému prostřednictvím vlastního formátu NST založeného na XML. Umožňují synchronizovat krizové plány vzniklé na různých místech. Přenášená data je možné digitálně podepsat a zašifrovat. A Systémová příručka Dokument obsahuje seznam a stručný popis modulů informačního systému KIS. Systém KIS obsahuje následující moduly (třídy): Třída Uzly zabezpečuje organizaci a správu dat v rozlišení podle jednotlivých uzlů. Je spojnicí mezi třídou Přenosy a ostatními třídami. Umožňuje členění dat na vlastní a okolní. Skládá se z komponent Správa uzlu a Nástroje uzlu. Třída Přenosy zabezpečuje správu datových toků mezi jednotlivými uzly systému. Zabezpečuje výměnu dat i v případě, kdy není KIS spojen v jednotné síti. Umožňuje digitální podpis a šifrování přenosů. Podporuje standard xml. Skládá se z komponent Řízení přenosů a Bezpečnost přenosů. Třída Datová základna uzlu zabezpečuje správu základních datových údajů. Třída je využívána jak třídou Krizové plánování, tak třídou Řešení krizových situací a zabezpečuje pro obě třídy jednotnou datovou základnu. Skládá se z komponent Organizace, Osoby, Smlouvy, Měrné jednotky, Nebezpečné látky, Prostředky a Sklady. Třída Krizové plánování obsahuje datové údaje a funkce pro krizové plánování. Skládá se z komponenty Zpracovatel, Ohrožení, Opatření a Dokumenty KP. V komponentě Zpracovatel je obsažena detailní informace o zpracovateli, jako je organizační struktura, struktura budov a areálu, organizace v součinnosti, sklady nebezpečných látek, stavy a potřeba zdrojů za běžné situace. V komponentě Ohrožení jsou funkce pro analýzu rizik. Tato analýza obsahuje vazby na různá opatření. V komponentě Opatření je uložen katalog opatření. Každé opatření představuje množinu činností s přiřazením zdrojů a vazeb mezi činnostmi. Činnosti v každém opatření mohou být hierarchicky strukturovány do složek až do hloubky čtyřiceti úrovní. V komponentě Dokumenty KP jsou uloženy struktura a obsah dokumentů krizového plánování. Třída Řešení krizových situací obsahuje datové údaje a funkce pro řešení krizových situací. Třída umožňuje simulaci mimořádných událostí, případně řízení a vyhodnocení skutečných událostí. Třída umožňuje spojování jednotlivých dlouhodobě plánovaných opatření do jednoho operačního plánu v závislosti na charakteru mimořádné události. Obsahuje zpětnou vazbu do krizového plánování. Umožňuje plánování počátečních stavů zdrojů pro řešení mimořádné události a bilancování zdrojů v průběhu řešení mimořádné události. Třída Mapa zabezpečuje správu a zobrazování geografických údajů. Výstupy a vstupy jsou přímo kompatibilní s formátem shp. Výstupy lze převádět do souborů typu bmp. Má přímou vazbu na vybrané objekty datové základny a na ohrožení. WAK-1F44C Str. 15

18 Třída Dokumentace umožňuje zobrazování údajů dokumentů krizového plánování prostřednictvím MS Word ve vazbě na dokumenty krizového plánování. Svazuje jednotlivé datové údaje uložené v systému KIS do podoby uceleného dokumentu okamžitě přenositelného do MS Word. Zabezpečuje integritu a verze generovaných dokumentů. Třída CPM obsahuje funkce pro časovou analýzu krizových plánů. Možnost sériového i paralelního řazení úkolů. Podporuje různé typy závislosti mezi složkami (etapami) v opatření. Třída vykonává funkce analýzy jak pro třídu Krizové plánování, tak pro třídu Řešení krizových situací. Třída Dotazy slouží pro snadný výběr a tisk datových údajů. Výsledky dotazů, stejně jako všechna tabulková zobrazení v systému KIS, lze okamžitě přenést do MS Excel. A.2 Analýza současného stavu řešení v doméně A.2.1 Přehled současných řešení Jako příklad krizového informačního systému, který je schopen vyměňovat data mezi lokálními instalacemi lze uvést informační systém KIS MDS. Tento systém používá pro výměnu dat vlastní formát NST, založený na technologii XML. Jedná se ve skutečnosti o XML dokument, volitelně šifrovaný a elektronicky podepsaný. Formát přenosové dávky je popsán následujícím DTD schématem: <!ENTITY %NAME "Name NMTOKEN #REQUIRED"> <!ELEMENT waknst(nstheader, nstdata, nstdeletedinfo)> <!ELEMENT nstheader(datdavky, uzlu?, gdavky, gtypupren, naztypupren, guzlu, nazuzlu, popisdavky?, nazdb, verdb, pubkeyuzlu?)> Hlavička přenosové dávky <!ELEMENT datdavky(#pcdata)> <!ELEMENT uzlu(#pcdata)> <!ELEMENT gdavky(#pcdata)> <!ELEMENT gtypupren(#pcdata)> <!ELEMENT naztypupren(#pcdata)> <!ELEMENT guzlu(#pcdata)> <!ELEMENT nazuzlu(#pcdata)> <!ELEMENT popisdavky(#pcdata)> <!ELEMENT nazdb(#pcdata)> <!ELEMENT verdb(#pcdata)> Datum dávky Adresa odesílatele GUID dávky Typ přenosu (viz dále) Název přenosu GUID uzlu odesílatele Název uzlu odesílatele Popis dávky Název databáze (Kis) Verze databáze WAK-1F44C Str. 16

19 <!ELEMENT pubkeyuzlu(#pcdata)> Veřejný RSA klíč odesílatele zakódovaný BASE64 <!ELEMENT nstdata(table+)> <!ELEMENT Table(Row+)> <!ATTLIST Name %NAME;> Data jednotlivých tabulek Tabulka Jméno tabulky <!ELEMENT Row(n.., g.., nuzlu, w_datupd,...)> Záznam tabulky <!ELEMENT n..(#pcdata)> <!ELEMENT g..(#pcdata)> <!ELEMENT nuzlu(#pcdata)> Primární klíč záznamu GUID záznamu Primární klíč uzlu, který pořídil záznam <!ELEMENT w_datupd(#pcdata)> Datum poslední modifikace <!ELEMENT nstdeletedinfo(table+)> <!ELEMENT Table(g+)> GUID smazaných záznamů v jednotlivých tabulkách Tabulka <!ATTLIST Name %NAME;> <!ELEMENT g (#PCDATA)> Jméno tabulky GUID záznamu Přenosový soubor má tedy tři části hlavičku, přenášená data a seznam GUID smazaných záznamů. Popis dávky není povinný, stejně jako není povinný veřejný RSA klíč uzlu, pokud se nevyužívá elektronický podpis. Přenášená data obsahují tagy Table se jmény tabulek. Každá tabulka obsahuje tagy Row s datu jednotlivých záznamů. Každý záznam je popsán tagy, odpovídající jeho polím. Z hlediska formátu NST jsou významná čtyři pole, která jsou obsažena v každé tabulce: n..(n + jméno tabulky, např. norg) primární klíč záznamu. g..(g + jméno tabulky, např. gorg) GUID záznamu. nuzlu Identifikátor uzlu. w_datupd Datum poslední modifikace záznamu. Technologie NST umožňuje dva formáty přenosové dávky XML a NST. Formát NST je XML formát opatřený hlavičkou a komprimovaným obsahem. Formát souboru NST je následující: Adresa Délka Popis 0H 2H Délka hlavičky v bytech 2H 3H Identifikátor NST 5H 1H Číslo verze 6H 1H Číslo subverze WAK-1F44C Str. 17

20 Adresa Délka Popis 7 4 Typ přenosu v NST vždy BH 4H Alg. komprese bez komprese gzip 0FH 4H Alg. šifrování bez šifrování rijndael 13H 4H Alg. podpisu bez podpisu RSA 17H 400H Klíč pro dešifrování obsahu šifrovaný algoritmem RSA 417H 80H Elektronický podpis obsahu 497H 497H 25H GUID dávky 4BC 25H GUID uzlu odesílatele 4E1H 25H GUID typu přenosu 506H FBH Název typu přenosu 601H FBH Název uzlu 6FCH FBH uzlu 7F7H 15H Datum dávky 80CH 100H Popis dávky 90CH 51H Název databáze 95DH 51H Verze databáze Kopie hlavičky přenosové dávky (tag nstheader) 9AEH 100H Veřejný klíč uzlu odesílatele AAEH 100H Data přenosové dávky (XML soubor), dle volby komprimovaný a šifrovaný Tab. A.2.1 Formát souboru NST V případě, že požadovaný formát dávky je XML a je požadován podpis, generuje se ještě soubor se stejným jménem a příponou SGN, který obsahuje podpis dávky. Šifrovat je možné dávku pouze ve formátu NST. Formát NST vyhovuje pro periodické aktualizace dat mezi instalacemi informačního systému KIS MDS. Obsahuje bezpečnostní prvky pro ověření autenticity přenosového souboru, resp. jeho zdroje a dovoluje šifrovat přenosový soubor silnou šifrou. Nevýhodou je naopak vazba na fyzický soubor systém KIS není schopen si vyměňovat data mezi uzly prostřednictvím webových služeb nebo jiného síťového protokolu. Nicméně vzhledem k ostatním kvalitám tohoto řešení k němu bude přihlédnuto při návrhu funkčnosti systému výměny dat pomocí webových služeb. Schopnost zpracovat a přenést soubor typu NST bude zařazena mezi funkční požadavky systému. A.2.2 Závěry ke stavu řešení Ačkoli se webové služby běžně používají pro výměnu dat mezi informačními systémy, není známo řešení, které by je používalo pro výměnu dat mezi krizovými informačními systémy. WAK-1F44C Str. 18