Výpoˇcty elektrické rozvodné s´ıtˇe v prostˇred´ı webu

(1)

V´ ypoˇ cty elektrick´ e rozvodn´ e s´ıtˇ e v prostˇ red´ı webu

Diplomov´ a pr´ ace

Studijn´ı program: N2612 – Elektrotechnika a informatika Studijn´ı obor: 1802T007 – Informaˇcn´ı technologie Autor pr´ace: Bc. Martin Bureˇs

Vedouc´ı pr´ace: Ing. Jana Vitvarov´a, PhD.

(2)

Web based calculations of power distribution network

Diploma thesis

Study programme: N2612 – Electrotechnology and informatics Study branch: 1802T007 – Information technology

Author: Bc. Martin Bureˇs

Supervisor: Ing. Jana Vitvarov´a, PhD.

(3)

(4)

(5)

(6)

Abstrakt

Diplomová práce popisuje návrh a vývoj softwarové platformy urˇcené k ˇreˇsen´ı vybraných vˇedeckých výpoˇct˚u nad elektrizaˇcn´ı soustavou v prostˇred´ı webu s vyuˇzit´ım souˇcasných webových technologi´ı. Jsou zde ˇreˇseny aktuáln´ı moˇznosti tvorby platformy z pohledu nároˇcných výpoˇcetn´ıch úloh, zp˚usob˚u ukládán´ı a sd´ılen´ı dat napˇr´ıˇc platformou, grafické vizualizace dat a propojen´ı s extern´ımi systémy. D˚uraz je kladen pˇredevˇs´ım na snadné a modulárn´ı vyuˇzit´ı sluˇzeb platformy v pˇr´ıpadˇe reálného nasazen´ı.

Kl´ıˇcová slova: web, webové sluˇzby, platforma, elektrizaˇcn´ı soustava, ustálený chod

Abstract

Diploma thesis describes the development of a software platform designed to solve selected scientific calculations on a power grid in a web environment using modern Web technologies. Current pos- sibilities for the platform development are examined from the per- spective of demanding computational tasks, ways of storing and sharing data across the platform, graphical data visualization and integration with external systems. The focus is primarily on an easy and modular use of the platform services in case of a real deploy- ment.

Keywords: web, web services, platform, electricity grid, steady state

(7)

Podˇ ekov´ an´ı

Dˇekuji Ing. Janˇe Vitvarové, Ph.D. za veden´ı mé diplomové práce.

Dále dˇekuji pracovn´ık˚um oddˇelen´ı Provozu ˇr´ıd´ıc´ıch systém˚u Východ – Hradec Králové ze spoleˇcnosti ˇCEZ Distribuce a.s. za konzultace a moˇznost ovˇeˇren´ı vytvoˇrených aplikac´ı v provozn´ıch podm´ınkách.

(8)

Obsah

Seznam zkratek . . . 9

1 Uvod´ 10 2 Anal´yza st´avaj´ıc´ıho stavu 11 2.1 Popis elektrizaˇcn´ı soustavy . . . 11

2.2 Syst´em RIS a jeho architektura . . . 12

3 N´avrh platformy 14 3.1 Poˇzadavky na funkˇcnost . . . 14

3.2 Potenci´aln´ı uˇzivatel . . . 15

3.3 Model platformy . . . 16

3.4 Datov´y model . . . 20

3.5 Provozn´ı prostˇred´ı . . . 21

3.6 Metodiky v´yvoje softwaru . . . 23

3.7 Techniky testov´an´ı softwaru . . . 24

3.8 Licence a dostupnost . . . 25

4 Poskytovatel identity 26 4.1 Identita uˇzivatele . . . 26

4.2 Autentizace . . . 27

4.3 Autorizace . . . 27

4.4 Implementace . . . 31

4.5 Testov´an´ı . . . 31

5 Aplikaˇcn´ı server 32 5.1 Princip webov´ych sluˇzeb . . . 32

5.2 Pˇrehled webov´ych sluˇzeb . . . 32

5.3 N´avrh API . . . 34

5.5 Testov´an´ı . . . 40

5.7 API Connector . . . 41

6 Editor 42 6.1 N´avrh aplikace . . . 42

(9)

6.3 Testov´an´ı . . . 46

7 Propojen´ı se syst´emy tˇret´ıch stran 47 7.1 Principy propojen´ı syst´em˚u . . . 47

7.2 Import dat . . . 48

7.3 Export dat . . . 51

8 Výpoˇcetn´ı úlohy 52 8.1 Výpoˇcetn´ı uzel . . . 52

8.2 Zivotn´ı cyklus ´ˇ ulohy . . . 53

8.3 Ust´alen´y chod ES . . . 53

8.4 Testov´an´ı . . . 56

9 Z´avˇer 57

Literatura 57

Obsah CD 60

Pˇr´ılohy 61

A ER model datab´aze Poskytovatel identit 62

B ER model datab´aze OAuth 63

C ER model datab´aze S´ıt’ 64

D ER model datab´aze V´ypoˇcty 65

E Editor – schema s´ıtˇe ˇZelkovice 66

F Editor – ovládán´ı úloh 67

(10)

Seznam zkratek

ES elektrizaˇcn´ı soustava

GUI graphical user interface, grafické uˇzivatelské rozhran´ı UI user interface, uˇzivatelské rozhran´ı

SaaS software as a service, software jako sluˇzba SPA single page application, jednostránková aplikace ER entity relation diagram, diagram vztah˚u mezi entitami URL uniform resource locator, jednotná adresa zdroje

FQDN fully qualified domain name, plnˇe specifikované doménové jméno poˇc´ıtaˇce CSV comma separated values, hodnoty oddˇelené oddˇelovaˇcem

XML extensible markup language, rozˇsiˇritelný znaˇckovac´ı jazyk JSON JavaScript Object Notation, formát zápisu dat

(11)

1 Uvod ´

Elektrická energie se stala souˇcást´ı ˇzivota bˇeˇzného ˇclovˇeka. Na jedné stranˇe stoj´ı spotˇrebitel, jehoˇz pˇrán´ım je, aby si mohl do elektrické zásuvky zapojit sv˚uj spotˇrebiˇc, a to kdykoli a na libovolnˇe dlouho. Na stranˇe druhé stoj´ı distribuˇcn´ı spoleˇcnost, a potaˇzmo vˇse s t´ım souvisej´ıc´ı od výroby aˇz po pˇrenos elektrické energie, jej´ımˇz

´

ukolem je zajiˇstˇen´ı pˇrepravy vyrobené elektrické energie ke koneˇcnému spotˇrebiteli.

Zde vstupuje v úvahu nespoˇcet dalˇs´ıch postup˚u, princip˚u, výpoˇct˚u aj. za úˇcelem bezchybného zajiˇstˇen´ı pˇrenosu elektrické energie. Jedná se o multioborovou vˇedn´ı problematiku se zastoupen´ım matematiky, fyziky, informatiky, energetiky aj.

Právˇe zm´ınˇená multiobornost se do znaˇcné m´ıry projevuje i v této diplomové práci. Jej´ım smyslem je bliˇzˇs´ı seznámen´ı s problematikou výpoˇctu ustáleného chodu ES pro následné potˇreby návrhu platformy, zp˚usoby jak výpoˇcty prakticky realizovat, a vhodným návrhem platformy, na které tyto operace budou provádˇeny. Svoje zastoupen´ı tak zde nacház´ı matematika i informatika, která je zde vˇsak pˇrevaˇzuj´ıc´ım prvkem zájmu. Proto je moˇzné tvrdit, ˇze smyslem této práce je vytvoˇrit takovou softwarovou platformu, na které bude moˇzné provádˇet vybrané typy úloh nad schematem ES. Pro dokreslen´ı kontextu pak bude prakticky implementována výpoˇcetn´ı

´

uloha ˇreˇs´ıc´ı ust´alen´y chod ES.

Jak je patrné ze samotného názvu této práce, tak nemalá ˇcást je zde vˇenována souˇcasným technologi´ım v prostˇred´ı webu. D˚uvod˚u je hned nˇekolik. Jedn´ım ze zásadn´ıch je fakt, ˇze souˇcasné programy ˇreˇs´ıc´ı stejnou problematiku jsou postavené pro desktopový provoz a z velké ˇcásti postrádaj´ı multiplatformn´ıˇreˇsen´ı. Nelze tvrdit, ˇze webové technologie jsou absolutnˇe multiplatformn´ı. V posledn´ı dobˇe vˇsak jejich vývoj k tomuto smˇeˇruje. Proto je vhodné prostˇrednictv´ım této práce prozkoumat, nakolik jejich vývoj pokroˇcil a zda-li jsou pouˇzitelné. S webovými technologiemi souvisej´ı i následuj´ıc´ı otázky. Jak se zmˇen´ı architektura systému zaveden´ım webových sluˇzeb? Je moˇzné nahradit desktopovou aplikaci aplikac´ı webovou? Pokud ano, pak v jakém rozsahu? Je moˇzné uvaˇzovat nasazen´ı takto upraveného systému (ve smyslu pouˇzit´ı webových technologi´ı) do produkˇcn´ıho prostˇred´ı?

Samotná práce je systematicky rozdˇelena do nˇekolika ˇcást´ı. V úvodu je struˇcnˇe popsán stávaj´ıc´ı stav. Na jeho základˇe je poté proveden návrh platformy, aby splˇnoval praktické poˇzadavky vzneˇsené od konzultanta a aby naplˇnoval zadán´ı této práce.

Následuj´ıc´ı kapitoly se postupnˇe zabývaj´ı bliˇzˇs´ım popisem jednotlivých komponent platformy.

(12)

2 Anal´ yza st´ avaj´ıc´ıho stavu

Diplomová práce navazuje na pˇredcházej´ıc´ı magisterský projekt (viz [1]), který se zabýval otázkou, jak uchovávat v poˇc´ıtaˇci reprezentaci ES. Jelikoˇz se jedná o téma vysoce odborné, celá práce byla konzultována s pracovn´ıky oddˇelen´ı Provozu ˇr´ıd´ıc´ıch systém˚u Východ – Hradec Králové ze spoleˇcnosti ˇCEZ Distribuce a.s.

Jak jiˇz bylo naznaˇceno v úvodu, tato práce se zabývá oblast´ı plánován´ı a ˇr´ızen´ı s´ıt´ı. Jelikoˇz se jedná obecnˇe o dosti ˇsiroké téma, práce se v teoretické rovinˇe zamˇeˇruje pouze na výpoˇcet ustáleného chodu ES. A právˇe touto problematikou, a mimo jiné i ˇradou dalˇs´ıch, se zabývaj´ı dalˇs´ı komerˇcnˇe dostupné systémy. Jedn´ım z nich je i systém RIS – SCADA/EMS od spoleˇcnosti ELEKTROSYSTEM, a.s. (viz [2]).

Z rize praktického d˚uvodu, kterým je pˇr´ıtomnost tohoto systému v ostrém provozu u konzultanta, bude i následnˇe uvaˇzováno pouˇzit´ı právˇe tohoto systému.

2.1 Popis elektrizaˇ cn´ı soustavy

Hlavn´ı úlohou ES je pˇrenos elektrické energie z m´ısta výroby (výrobci) do m´ısta spotˇreby (spotˇrebitelé). Je tvoˇrena souhrnem veden´ı, které m˚uˇze vést vzduchem, pomoc´ı r˚uzných typ˚u stoˇzár˚u nebo se m˚uˇze jednat o kabelovou variantu. Dále je dˇelena na pˇrenosovou s´ıt’, která vytváˇr´ı pˇrenosovou cestu mezi centry výroby a spotˇreby, a distribuˇcn´ı s´ıt’, která slouˇz´ı k pˇrenosu elektrické energie ke koncovým spotˇrebitel˚um.

ES je v poˇc´ıtaˇci reprezentována schematem. Schema je mnoˇzina prvk˚u, které dohromady vytváˇrej´ı ES. Samotné prvky soustavy lze rozdˇelit do tˇr´ı kategori´ı –

´

useky, uzlové body a objekty. Pro ˇreˇsen´ı úlohy ustáleného chodu ES jsou pouˇzity pouze prvn´ı dvˇe kategorie prvk˚u.

Usek je takov´´ y prvek soustavy, který spojuje alespoˇn dva rozd´ılné uzlové body a m˚uˇze nabývat typu:

• veden´ı,

• transform´ator,

• trojvinut’ov´y transform´ator,

• reaktor,

• sp´ınac´ı prvek.

(13)

Uzlový bod je takový prvek soustavy, který m˚uˇze být propojen s ostatn´ımi uzlovými body za pomoci úseku a m˚uˇze nabývat typu:

• nap´ajec´ı bod,

• odbˇern´y bod,

• turbogener´ator,

• hydrogener´ator,

• nadˇrazen´a soustava.

Objekt je takový prvek soustavy, který seskupuje vybrané uzlové body. Pro

´

uˇcely ˇreˇsen´ı úloh neposkytuje ˇzádné relevantn´ı informace. Jeho pouˇzit´ı je zejména pro organizaci uzlových bod˚u.

Jedn´ım z výstup˚u zm´ınˇeného magisterského projektu (viz [1]) byl jazyk popisuj´ıc´ı schema s´ıtˇe a jeho prvky. Byl vytvoˇren v jazyce XML, který i pˇres svoj´ı koˇsatˇejˇs´ı strukturu velmi pˇresnˇe vyjadˇruje vztah jednotlivých prvk˚u a jejich atribut˚u. Právˇe z takto popsaného schematu soustavy bude dále moˇzné vycházet pˇri návrhu zm´ınˇené platformy.

2.2 Syst´ em RIS a jeho architektura

R´ıd´ıc´ı syst´ˇ em RIS – SCADA/EMS vytvoˇrila spoleˇcnost ELEKTROSYSTEM, a.s.

(viz [2]). Jedná se o komerˇcn´ı produkt, který je navrˇzen pˇredevˇs´ım pro distribuˇcn´ı spoleˇcnosti s potˇrebou ˇr´ızen´ı jejich distribuˇcn´ı s´ıtˇe. Obsahuje mnoho funkcionalit a komponent, mezi kterými je napˇr. editor schematu soustavy, který umoˇzˇnuje vytváˇret i editovat soustavy. Dalˇs´ı jeho komponenty pak ˇreˇs´ı estimaci chodu s´ıtˇe, kontingenˇcn´ı analýzu, chod s´ıtˇe, výpoˇcty zkrat˚u, výpoˇcty topologie, ale i samotné ˇr´ızen´ı sbˇeru dat z energetických objekt˚u. Nab´ız´ı také funkcionalitu dispeˇcerského ˇr´ızen´ı zvolené s´ıtˇe. Systém se skládá z nˇekolika hlavn´ıch ˇcást´ı, které jsou zachyceny na obrázku 2.1. Kaˇzdá jednotlivá ˇcást mus´ı být ve funkˇcn´ım systému zastoupena nejménˇe jednou instanc´ı, coˇz je na uvedeném obrázku vyjádˇreno symbolicky jako 1:N. Patˇr´ı mezi nˇe:

• datové servery (DS), které zajiˇst’uj´ı chod systému,

• servery vzdálených uˇzivatel˚u (VU), které zajiˇst’uj´ı vzdálené pˇripojen´ı do pod- nikové s´ıtˇe,

• telemetrické servery (TS), jejichˇz hlavn´ı nápln´ı je sbˇer dat ze vzdálených objekt˚u,

• servery vyˇsˇs´ıch energetických funkc´ı (ES), které realizuj´ı numerické výpoˇcty vyˇsˇs´ıch funkc´ı,

• uˇzivatelské stanice (US), pomoc´ı kterých lze systém obsluhovat.

(14)

Z obrázku 2.1 je dále patrné, ˇze celý tento systém pouˇz´ıvá pro komunikaci TCP/IP protokol. Vzhledem k potˇrebˇe spojen´ı objekt˚u, které jsou r˚uznˇe geograficky um´ıstˇené, se pro úˇcely spojen´ı pouˇz´ıvaj´ı r˚uzné technologie od dedikovaných okruh˚u poˇc´ınaje aˇz po VPN pˇripojen´ı. To zajist´ı, ˇze veˇskeré objekty, které podléhaj´ı vzdálenému ˇr´ızen´ı, vytváˇr´ı v distribuˇcn´ı oblasti (Východn´ı ˇCechy) privátn´ı, tzv. podnikovou, s´ıt’. Ta je pak dále spojena s ostatn´ımi distribuˇcn´ımi s´ıtˇemi v rámci distributora.

Z dokumentace téˇz vyplývá, ˇze systém RIS nen´ı multiplatformn´ı. Pˇreváˇzná vˇetˇsina server˚u je provozována na operaˇcn´ım systému Linux. Existuj´ı d´ılˇc´ı programy, které jsou spustitelné pouze pod operaˇcn´ım systémem Windows. Vzhledem k tomu, ˇze se jedná právˇe o stˇeˇzejn´ı jádro celého systému, bez kterého se ˇzádná z uˇzivatelských stanicic neobejde, je nam´ıstˇe konstatován´ı oné nemultiplatformosti. Výjimkou jsou pak uˇzivatelské stanice ve formˇe desktopových aplikac´ı, které by mˇely fungovat, jak na operaˇcn´ım systému Linux, tak i Windows.

Obr´azek 2.1: Architektura syst´emu RIS

(15)

3 N´ avrh platformy

Platforma je definována jako prostˇred´ı po stránce hardwarové i softwarové, které umoˇzˇnuje bezproblémový chod aplikac´ı na n´ı provozovaných. Nen´ı bez zaj´ımavosti, ˇze v dneˇsn´ı praxi se zejména pro komplexnˇejˇs´ı aplikace ˇci úlohy toto slovo vyskytuje pomˇernˇe ˇcasto. Mnohdy je totiˇz potˇreba sladit ˇcinnost v´ıce aplikac´ı, které by mˇely právˇe poskytovat urˇcité bˇehové prostˇred´ı. A t´ım jsme se dostali zpátky ke slovu platforma. Je moˇzná ambiciózn´ı toto slovo pouˇz´ıvat. Zvláˇstˇe v kontextu diplomové práce a za podm´ınek ve kterých vznikala. Nicménˇe právˇe toto slovo nejlépe vystihuje pˇresnˇe tu mnoˇzinu aplikac´ı, funkˇcnosti, nápad˚u a ˇreˇsen´ı, kterými se diplomová práce dále zabývá.

3.1 Poˇ zadavky na funkˇ cnost

Mezi základn´ı poˇzadavky na funkcionalitu platformy, které samozˇrejmˇe vycházej´ı z reálné potˇreby a konzultac´ı, jsou zaˇrazeny následuj´ıc´ı.

1. Navrhnout a vytvoˇrit jako volnˇe ˇsiˇritelný software a vyuˇz´ıt volnˇe dostupné technologie (i z hlediska pˇr´ıpadného budouc´ıho komerˇcn´ıho vyuˇzit´ı).

2. V pˇr´ıpadˇe vhodnosti pouˇz´ıt webov´e technologie.

3. Vˇsechny aplikace v rámci platformy vytvoˇrit jiˇz od poˇcátku s distribuovanou architekturou tak, aby byly dobˇre ˇskálovatelné. Klást d˚uraz na multiplatformn´ı ˇreˇsen´ı.

4. Identity uˇzivatel˚u spravovat centrálnˇe spolu s jejich pˇr´ıstupovými údaji vˇcetnˇe moˇznosti vytváˇren´ı úˇcelových pˇr´ıstupových údaj˚u ke konkrétn´ım aplikac´ım.

5. Provádˇet autentizaci a autorizaci prostˇrednictv´ım centráln´ıho pˇr´ıstupového bodu. Zde klást d˚uraz na ochranu pˇr´ıstupových údaj˚u a jejich sdˇelován´ı pouze d˚uvˇeryhodné autentizaˇcn´ı stranˇe.

6. Vyˇzadovat pˇr´ıstupové oprávnˇen´ı k pˇr´ıstupu do schematu s´ıtˇe a k zadáván´ı výpoˇcetn´ı úlohy vytvoˇrené nad zvoleným schematem. ˇZádné dalˇs´ı omezen´ı pˇr´ıstupu k jednotlivým aplikac´ım ˇci jejich ˇcástem nen´ı poˇzadováno.

7. Vytvoˇrit editor schematu s´ıtˇe s moˇznost´ı editace prvk˚u, grafické vizualizace schematu a zadáván´ı výpoˇcetn´ıch úloh. Jiné poˇzadavky na jeho UI nejsou.

(16)

Nicménˇe je nutné pˇri jeho návrhu brát v potaz pˇrehlednost a srozumitelnost pro koncového uˇzivatele.

8. V pˇr´ıpadˇe pouˇzit´ı webov´ych technologi´ı jako UI vˇzdy kl´ast d˚uraz na responzivn´ı design.

9. Provést import dat ze systému RIS. Nen´ı jej tˇreba integrovat do editoru, postaˇc´ı spouˇstˇen´ı z terminálu a následný import provedený z pˇredávac´ıho formátu. Uvaˇzovat moˇzné budouc´ı rozˇs´ıˇren´ı v implementaci jiného formátu.

10. Implementovat výpoˇcetn´ı úlohu ustáleného chodu s´ıtˇe.

3.2 Potenci´ aln´ı uˇ zivatel

Potenciáln´ıch uˇzivatel˚u je nˇekolik skupin. Spoleˇcným zájmem následnˇe identifiko- vaných skupin uˇzivatel˚u je skuteˇcnost, ˇze tato platforma je koncipována jako volnˇe ˇsiˇritelná s otevˇreným zdrojovým kódem. Pˇrestoˇze je pravdou, ˇze u takto zaloˇzených projekt˚u rozhoduje o jejich pˇreˇzit´ı podpora ze strany komunity ˇci alespoˇn v˚ule vývojáˇr˚u pokraˇcovat ve vývoji, tak i pˇres tuto skuteˇcnost se jedná o ve své oblasti nezanedbatelný krok kupˇredu a je jen na kaˇzdém uˇzivateli, zda si projekt osvoj´ı.

Prvn´ı skupinou jsou distribuˇcn´ı spoleˇcnosti provozuj´ıc´ı distribuˇcn´ı soustavy.

Vzhledem k faktu, ˇze tato práce vznikala za pomoci konzultac´ı s pracovn´ıky právˇe takové spoleˇcnosti, je zˇrejmé, ˇze toto je jeden z potenciáln´ıch uˇzivatel˚u. Byt’ se ne- jedná v ˇzádném pˇr´ıpadˇe o náhradu jiˇz pouˇz´ıvaných dispeˇcerských a jiných systém˚u, tak tato platforma si m˚uˇze naj´ıt své uplatnˇen´ı jako alternativn´ı nástroj pro nároˇcnˇejˇs´ı matematické výpoˇcty vybraných typ˚u úloh, které si jej´ı provozovatel m˚uˇze sám modifikovat dle svých pˇrán´ı. Ne kaˇzdému totiˇz m˚uˇze vyhovovat uzavˇrenost dnes pouˇz´ıvaných systém˚u.

Druhou skupinou jsou pak samostatn´ı projektanti elektrických s´ıt´ıˇci spoleˇcnosti zabývaj´ıc´ı se t´ımto oborem. I v tomto pˇr´ıpadˇe hraje roli potˇreba provádˇen´ı výpoˇct˚u vybraných typ˚u úloh. Ve spojen´ı s r˚uznými moˇznostmi provozu platformy, moˇznostem k jej´ım úpravám (samozˇrejmˇe v pˇr´ıpadˇe potˇreby) a své dostupnosti, se m˚uˇze jevit jako zaj´ımavá moˇznost.

Následuj´ıc´ı skupina se od pˇredchoz´ıch odliˇsuje t´ım, ˇze se ve své podstatˇe ne- jedná o uˇzivatele platformy, nýbrˇz o jej´ıho provozovatele. Tuto platformu by mohl provozovatel provozovat i jako SaaS, kdy zákazn´ık vyuˇz´ıvá sluˇzby platformy a jej´ı provozovatel si na n´ı t´ımto zp˚usobem realizuje podnikatelský zámˇer. Pro úˇcely této práce vˇsak tato moˇznost rozhodnˇe nen´ı prioritn´ı a jedná se tak pouze o úvahu.

Posledn´ı skupinu tvoˇr´ı lidé ˇci instituce, které tuto platformu vyuˇzij´ı k edukativn´ım úˇcel˚um. Ne ˇze by nebylo moˇzné ji provozovat z edukativn´ıch úˇcel˚u i pro výˇse uvedené typy uˇzivatel˚u, ale u nich se pˇredpokládá sp´ıˇse praktické vyuˇzit´ı na základˇe reálných potˇreb.

(17)

3.3 Model platformy

3.3.1 Komponenty

Na základˇe poˇzadavk˚u uvedených v kapitole 3.1 jsou definovány základn´ı komponenty platformy. Jak vyplývá z tˇret´ıho poˇzadavku, vˇsechny komponenty jsou navrˇzeny s ohledem na distribuovatelnost. T´ım je myˇsleno, aby kaˇzdá z komponent byla pˇripravená na ˇskálovatelnost, na zvýˇsen´ı jej´ıho výkonu, kapacity, ˇci prostého fyzického oddˇelen´ı od zbytku platformy v pˇr´ıpadˇe potˇreby.

Prvn´ı takovou komponentou je Poskytovatel identit (IdP). Jej´ım úkolem je správa identity jednotlivých uˇzivatel˚u a k n´ı pˇr´ısluˇsej´ıc´ı pˇr´ıstupové údaje. Dalˇs´ı neménˇe významnou funkc´ı je provádˇen´ı ovˇeˇrován´ı uˇzivatel˚u, kteˇr´ı se pokouˇsej´ı k plat- formˇe pˇristoupit a udˇelit jim patˇriˇcná oprávnˇen´ı. A v okamˇziku pˇr´ıchoz´ıho poˇzadavku vˇzdy ovˇeˇrit, ˇze daný poˇzadavek a jeho p˚uvodce, uˇzivatel, sm´ı daný poˇzadavek provést.

Dalˇs´ı komponentou, z poˇzadavk˚u vyplývaj´ıc´ı, je Editor. Prostˇrednictv´ım komponenty editoru z´ıská uˇzivatel pˇr´ıstup k uloˇzeným dat˚um, a to at’ uˇz v textové ˇci grafické podobˇe. Textovou podobou je myˇslena moˇznost náhledu a úprav pomoc´ı formuláˇr˚u ˇci jiných k tomu potˇrebných prostˇredk˚u tak, aby mˇel uˇzivatel moˇznost s daty pracovat. Grafickou podobou je myˇslena moˇznost vizualizace vybraných dat.

V tomto pˇr´ıpadˇe lze uvaˇzovat vizualizaci vytvoˇreného schematu s´ıtˇe, jelikoˇz to obsahuje vˇsechny pouˇzité prvky soustavy a dává ucelený pohled na n´ı samotnou prostˇrednictv´ım grafu s´ıtˇe.

Spolupráci s extern´ımi programy, prozat´ım ve formˇe pˇreb´ırán´ı dat z extern´ıho systému, ˇreˇs´ı komponenta Import dat. Tato funkcionalita je dostupná z toho d˚uvodu, aby bylo moˇzné z extern´ıho systému importovat jiˇz existuj´ıc´ı data. V tomto pˇr´ıpadˇe data o schematu s´ıtˇe. Vzhledem k faktu, ˇze je zde kladen d˚uraz na jistou modularitu, tak tato komponenta je navrˇzena zp˚usobem, aby se dala upravovat pro r˚uzné konkrétn´ı programy. Praktická implementace je zamˇeˇrena na systém RIS.

Posledn´ı komponentou vyplývaj´ıc´ı z poˇzadavk˚u jsou Výpoˇcty úloh. Vzhledem k faktu, ˇze existuje v´ıce typ˚u výpoˇcetn´ıch úloh, které lze nad daným schematem s´ıtˇe provádˇet, a s pˇrihlédnut´ım k výkonovým moˇznostem r˚uzných dále popsaných variant, je zapotˇreb´ı klást u této komponenty d˚uraz na modulárnost, ˇskálovatelnost a vhodné techniky jej´ıho zpracován´ı.

3.3.2 Uloˇ ´ ziˇ stˇ e dat

Poˇzadavky v kapitole 3.1 nikterak nespecifikuj´ı zp˚usob uloˇzen´ı dat a jejich pˇr´ıpadné sd´ılen´ı napˇr´ıˇc zm´ınˇenými komponentami. Toho lze dosáhnout r˚uznˇe.

Prvn´ı variantou je, ˇze kaˇzdá komponenta má vlastn´ı úloˇziˇstˇe dat, které spravuje.

Tento pˇr´ıstup má relativn´ı výhodu v tom, ˇze nepˇridává do platformy dalˇs´ı komponenty. Nicménˇe vˇetˇs´ı nevýhodou se jev´ı jejich vzájemné provázán´ı a následná správa.

Druhá varianta tento problém ˇreˇs´ı za pomoci centráln´ıho úloˇziˇstˇe dat pro veˇskeré komponenty. To je realizováno prostˇrednictv´ım databáze. Tento pˇr´ıpad je zachycen na obrázku 3.1.

(18)

Obrázek 3.1: Model platformy s centráln´ım úloˇziˇstˇem

Avˇsak i pro tento pˇr´ıpad existuje negativn´ı d˚uvod, proˇc jej nezvolit. T´ım d˚uvodem je závislost na konkrétn´ı pouˇzité databázi. V pˇr´ıpadˇe jej´ı zmˇeny ˇci výmˇeny za jinou by bylo potˇreba zasahovat do jednotlivých komponent. Pˇrestoˇze dnes nen´ı prakticky problém vytváˇret konkrétn´ı komponenty s dostateˇcnou abstrakc´ı a poté jen konfigurac´ı nastavit konkrétn´ı databázi, minimálnˇe v tomto lze spatˇrovat onu nutnou modifikaci. Jej´ı výhodou se jev´ı rychlost zpracován´ı poˇzadavk˚u, protoˇze poˇzadavky zpracovává pˇr´ımo databázový stroj.

Tˇret´ı variantou je pouˇzit´ı aplikaˇcn´ıho serveru (AS). Tento pˇr´ıpad je znázornˇen na obrázku 3.2. Zde je patrné, ˇze prostˇredn´ıkem pro výmˇenu dat mezi komponentami (aplikacemi) a databáz´ı je aplikaˇcn´ı server. Ten m˚uˇze podporovat r˚uzné zp˚usoby zpracován´ı poˇzadavk˚u a odpovˇed´ı a také jejich r˚uzné formáty. O této problematice bl´ıˇze pojednává kapitola 5. V kontextu pˇredchoz´ıho odstavce je nutné zm´ınit, ˇze tato varianta m˚uˇze být v urˇcitých situac´ıch výkonovˇe horˇs´ı, protoˇze m´ısto pˇr´ımého pˇr´ıstupu komponenty (aplikace) do databáze se ona komponenta obrac´ı de facto na prostˇredn´ıka, který ji poˇzadovanou akci zprostˇredkuje. V dneˇsn´ı dobˇe existuj´ı techniky, napˇr. vhodné cachován´ı dat, s nimiˇz lze tyto problémy minimalizovat.

Na druhou stranu zde existuje minimálnˇe jedna nepˇrehlédnutelná výhoda. Tou je moˇznost specifikace daného rozhran´ı nezávisle na pouˇzité databázi a odst´ınˇen´ı konkrétn´ı komponenty od nutnosti pˇresnˇe implementovat danou databázi. V praxi se jedná o to, ˇze aplikaˇcn´ı server poskytuje rozhran´ı ve formˇe definovaných struk- tur volán´ı ˇci pˇr´ıstupu k dat˚um. Tato volán´ı pak provád´ı komponenta, která nemus´ı ˇreˇsit, jak se data internˇe ukládaj´ı. Pro ni je pouze d˚uleˇzité, aby dokázala pracovat s daným rozhran´ım, které ji zpˇr´ıstupˇnuje aplikaˇcn´ı server. To pˇrináˇs´ı i druhou výhodu. Je pˇredem jasné, ˇc´ım aplikaˇcn´ı server disponuje a co naopak nepodporuje.

(19)

Ke kaˇzdému takovému rozhran´ı by se mˇela vytváˇret dokumentace, aby programátor vˇedˇel, co a jak m˚uˇze v rámci sluˇzeb aplikaˇcn´ıho serveru vyuˇz´ıt.

Obr´azek 3.2: Model platformy s aplikaˇcn´ım serverem

Na základˇe pˇredchoz´ıho srovnán´ı modelu bez aplikaˇcn´ıho serveru a s jeho pouˇzit´ım bylo zvoleno ˇreˇsen´ı, které jej vyuˇz´ıvá. Krom výˇse uvedených výhod tohoto ˇreˇsen´ı lze pˇridat jeˇstˇe jednu dalˇs´ı. Tou je skuteˇcnost, ˇze aplikaˇcn´ı server lze vytvoˇrit i jako webovou sluˇzbu, resp. aplikaˇcn´ı server poskytuj´ıc´ı webové sluˇzby.

3.3.3 Realizovatelnost komponent

Vzhledem k pˇredeˇslé volbˇe aplikaˇcn´ıho serveru je moˇzné konfrontovat tuto skuteˇcnost s výˇse uvedenými komponentami. Smyslem této konfrontace je pouze zjistit, zda-li je daná komponenta realizovatelná v˚uˇci aplikaˇcn´ımu serveru.

Prvn´ı zm´ınˇenou komponentou je Poskytovatel identit. Z obrázku 3.2 je pa- trné, ˇze ten pˇr´ımo s aplikaˇcn´ım serverem nekomunikuje. Pˇresto je zde jeden jediný okamˇzik, kdy docház´ı k nepˇr´ımé komunikaci. T´ımto je okamˇzik pˇr´ıchoz´ıho poˇzadavku na aplikaˇcn´ı server, kdy poskytovatel identit ovˇeˇr´ı, zda je poˇzadavek validn´ı po stránce autorizaˇcn´ı. Tohoto ovˇeˇren´ı se vˇsak m˚uˇze zhostit aplikaˇcn´ı server sám, jelikoˇz sám má pˇr´ıstup k databázi uchovávaj´ıc´ı autorizaˇcn´ı záznamy. Autorizaˇcn´ı záznam mus´ı vˇzdy vytvoˇrit poskytovatel identit. Následné ovˇeˇren´ı spoˇc´ıvá pouze v kontrole jeho existence, coˇz je moˇzné provádˇet aplikaˇcn´ım serverem. Je moˇzné konstatovat, ˇze tato komponenta je realizovatelná. Lze ji také vytvoˇrit jako webovou aplikaci.

Pro spr´avu identit ˇci pˇr´ıstup k platformˇe tato skuteˇcnost nepˇredstavuje omezen´ı.

Vytvoˇren´ı Editoru, jako webové aplikace, je bez jakéhokoli omezen´ı, ba naopak navazuje v duchu webu a jeho sluˇzeb na pˇredeˇslé. Je moˇzné jej realizovat bud’ jako

(20)

klasickou webovou aplikaci nebo téˇz jako tzv. single page aplikaci. Ta se vyznaˇcuje t´ım, ˇze aplikaˇcn´ı server slouˇz´ı pouze jako zdroj obsahu a veˇskerý kód aplikace samé je interpretován na klientovi v jeho prohl´ıˇzeˇci. Co se výˇse uvedené funkcionality týká, toto ˇreˇsen´ı dokáˇze pokrýt veˇskeré poˇzadavky. Tedy jak moˇznost práce s daty ve formˇe jejich úprav prostˇrednictv´ım formuláˇr˚u, tak i vizualizaci schematu s´ıt´ı.

Komponentu Import dat je tˇreba hodnotit ze dvou pohled˚u. Jednak je to implementace, která realizuje vlastn´ı proveden´ı importu dat nezávisle na GUI. Tato ˇcást se jev´ı jako nekonfliktn´ı v˚uˇci aplikaˇcn´ımu serveru a poskytovateli identit, protoˇze pouze vyuˇz´ıvá jimi poskytované sluˇzby. Druhý pohled je pak samotné GUI. V poˇzadavc´ıch kapitoly 3.1 se pro tuto komponentu uvád´ı, ˇze nen´ı potˇreba se zabývat GUI, nýbrˇz ˇze staˇc´ı pouze UI ve formˇe terminálového ovládán´ı spouˇstˇené aplikace. I tento pohled je nekonfliktn´ı. Z toho tedy vyplývá, ˇze komponenta import m˚uˇze být vytvoˇrena jako terminálová aplikace ovladatelná pˇr´ıkazy terminálu. To je vlastnˇe pˇredstupnˇem pro desktopovou grafickou nadstavbu. Nyn´ı se nab´ız´ı otázka, proˇc by to nemohla být webová aplikace. Samozˇrejmˇe ˇze by j´ı mohla být. Úlohou této komponenty je importovat i rozsáhlá data. A to je v rámci webové aplikace pˇrinejmenˇs´ım znaˇcnˇe diskutabiln´ı. Taková aplikace by totiˇz potˇrebovala prakticky neomezený ˇcas bˇehu j´ı samé. T´ım je m´ıˇreno na interpretované jazyky na webovém serveru s nastavenou maximáln´ı dobou trván´ı daného skriptu. Právˇe ta by mohla zp˚usobit jeho pˇredˇcasné ukonˇcen´ı dˇr´ıve neˇz se dané operace dokonˇc´ı. Je tu moˇznost toto nastaven´ı upravit, nicménˇe je otázkou, zda-li by se i po této úpravˇe jednalo o vhodnou volbu tˇreba právˇe z hlediska výkonu.

Posledn´ı komponentou je komponenta Výpoˇct˚u úloh. Jej´ım úkolem je, jak jiˇz název napov´ıdá, provádˇen´ı výpoˇct˚u matematických úloh. Je zˇrejmé, ˇze v prvn´ı ˇradˇe hraje roli efektivita výpoˇctu spolu s dostupným výpoˇcetn´ım výkonem. Poˇzadavky typu paralelizovatelnost ˇci v´ıce vláknové zpracován´ı jsou na pˇredn´ıch pˇr´ıˇckách. Právˇe z tohoto d˚uvodu je prakticky vylouˇcené, aby výpoˇcty provádˇel webový prohl´ıˇzeˇc uˇzivatele. Pˇrestoˇze jiˇz dnes nˇekteré webové prohl´ıˇzeˇce pracuj´ı tak, ˇze kaˇzdý otevˇrený panel bˇeˇz´ı ve svém vlastn´ım procesu, stále se nedá mluvit o dostateˇcnˇe dostupném výkonu. Tˇeˇzko si pˇredstavit uˇzivatele, který si ve svém webovém prohl´ıˇzeˇci, byt’

pouze v jednom panelu, spust´ı nˇejaký rozsáhlejˇs´ı výpoˇcet. Nemluvˇe o situaci, kdy je potˇreba provádˇet v´ıce výpoˇct˚u souˇcasnˇe. Proto lze konstatovat, ˇze webové prohl´ıˇzeˇce, resp. webové aplikace, jsou pro tento úˇcel jen stˇeˇz´ı pouˇzitelné a pro praktický bˇeh platformy sp´ıˇse nevhodné. V tomto smˇeru má vˇetˇs´ı perspektivu tuto komponentu navrhnout jako systémovou sluˇzbu, která se spouˇst´ı na pozad´ı. ˇSkálovatelnost je v tomto pˇr´ıpadˇe moˇzná jak výbˇerem vhodného hardwaru, tak i prostým pˇridáván´ım výpoˇcetn´ıch uzl˚u ˇci pˇresunut´ı výpoˇct˚u do specializovaných cluster˚u. Webová aplikace by mohla dané výpoˇcty ovládat, napˇr´ıklad prostˇrednictv´ım aplikaˇcn´ıho serveru, ale nikoli provádˇet.

Tato kapitola se tak vlastnˇe stala zdrojem odpovˇed´ı otázky poloˇzené v úvodu této diplomové práce. Odpov´ıdá na stˇeˇzejn´ı otázky, kdy, kde a zda má smysl pouˇz´ıt webové technologie. Jejich pouˇzit´ı je popsáno v kapitolách jednotlivých komponent.

(21)

3.4 Datov´ y model

V návaznosti na pˇredchoz´ı kapitolu, která dospˇela k závˇeru, ˇze vhodnˇejˇs´ı je zvolit model s aplikaˇcn´ım serverem, je nyn´ı zapotˇreb´ı alespoˇn v základn´ım rámci definovat strukturu úloˇziˇstˇe dat. To vˇse samozˇrejmˇe s pˇrihlédnut´ım k jiˇz z´ıskaným poznatk˚um o struktuˇre jednotlivých prvk˚u schematu s´ıtˇe a schematu samotnému, které byly zjiˇstˇeny a popsány v magisterském projektu (viz [1]).

Navrhnout vhodný model lze v´ıce zp˚usoby. Avˇsak c´ılem práce nen´ı se zabývat zdaleka vˇsemi moˇznostmi. Proto je zde vˇenován prostor pro dva, byt’ na prvn´ı pohled odliˇsné, ale pˇri bliˇzˇs´ım pohledu do znaˇcné m´ıry shodné, modely.

3.4.1 Varianty datov´ eho modelu

Prvn´ı pˇr´ıstup k vytvoˇren´ı modelu spoˇc´ıvá ve vytvoˇren´ı jedné jediné databáze, ve které by byly reprezentovány vˇsechny potˇrebné entity s patˇriˇcnými vzájemnými relacemi. To tedy znamená, ˇze databáze je jeden logický celek, který internˇe obsahuje jednotlivé entity. Z pohledu výkonnostn´ıho je zˇrejmé, ˇze databázový stroj je nutné provozovat v dostateˇcnˇe výkonném prostˇred´ı. Toho lze dosáhnout jednak hardwarovˇe na samostatném serveru, ale i za pouˇzit´ı databázového clusteru, kdy existuj´ı r˚uzné techniky, jak rozloˇzit zátˇeˇz kladenou na cluster. Pro ilustraci lze uvést architekturu Master-Slave, kdy uzel typu Master provád´ı úpravy uloˇzených dat a distribuuje tyto

´

upravy dále na uzly typu Slave, které slouˇz´ı pro jejich z´ıskáván´ı. Dalˇs´ım typem je pak cluster s architekturou Multi-Master, který obsahuje uzly typu Master a data jsou vzájemnˇe mezi vˇsemi replikována.

Druhým pˇr´ıstupem je seskupen´ı entit do logických celk˚u, které jsou reprezen- továny samostatnými databázemi. Tento pˇr´ıstup skýtá moˇznosti vˇetˇs´ı distribuo- vatelnosti neˇz pˇredchoz´ı, jelikoˇz lze, at’ uˇz v rámci jednotlivých server˚u, ˇci pˇr´ımo cluster˚u, fyzicky oddˇelit jednotlivé databáze. Nicménˇe právˇe tento pˇr´ıstup k návrhu je nároˇcnˇejˇs´ı, coˇz vyplývá z onoho oddˇelen´ı jednotlivých databáz´ı. V pˇr´ıpadˇe provozu takovýchto databáz´ı v rámci jednoho databázového serveru ˇci databázového clusteru je toto ˇreˇsen´ı praktické. Nen´ı vˇsak pˇr´ıliˇs vhodné pro situaci, kdy budou jednotlivé databáze provozovány separátnˇe a bez propojen´ı s ostatn´ımi. To z toho d˚uvodu, ˇze by pak byly omezeny dotazy nad v´ıcero entitami z r˚uzných databáz´ı.

3.4.2 N´ avrh datov´ eho modelu

Následuj´ıc´ı obrázek 3.3 zachycuje model vytvoˇrený druhým pˇr´ıstupem. Je z nˇej patrná existence nˇekolika databáz´ı, kdy kaˇzdá z nich obsahuje logicky spˇr´ıznˇené entity. Je vˇsak nutné na tomto m´ıstˇe zm´ınit, ˇze tento obrázek pouze schematicky zobrazuje vztah jednotlivých databáz´ı a nastiˇnuje entity, které jsou v nich um´ıstˇeny.

Nejedná se tedy o ER diagram v pravém slova smyslu, nýbrˇz pouze o vyjádˇren´ı logických vazeb mezi databázemi za pomoci symboliky z ER diagramu.

Datab´aze S´ıt’ obsahuje entity popisuj´ıc´ı schema s´ıtˇe. Jedn´a se tedy napˇr. o schema,

´

useky, uzlové body, objekty, atd. Dalˇs´ı databáz´ı je pak Identita. Ta má uchovávat data souvisej´ıc´ı s identitou uˇzivatele a jeho pˇr´ıstupovým úˇctem. V tˇesné spolupráci

(22)

Obrázek 3.3: Návrh datového modelu

s databáz´ı Identita funguje databáze OAuth, která obsahuje entity souvisej´ıc´ı s autorizac´ı uˇzivatel˚u. Samotný princip autorizace je následnˇe uveden v kapitole 4.3. Pro potˇreby správy jednotlivých výpoˇcetn´ıch úloh slouˇz´ı databáze Výpoˇcty. Posledn´ı databáz´ı je Editor, který uchovává data a nastaven´ı editoru.

Detailn´ı struktura jednotlivých databáz´ı je zachycena v pˇr´ılohách. ER diagram v pˇr´ıloze A zobrazuje databázi poskytovatele identit, v pˇr´ıloze B databázi OAuth, v pˇr´ıloze C databázi s´ıtˇe a v pˇr´ıloze D databázi výpoˇct˚u.

3.5 Provozn´ı prostˇ red´ı

Z pˇredchoz´ıch kapitol je jiˇz zˇrejmé, jaké komponenty by mˇela vytváˇrená platforma obsahovat. Nyn´ı pˇricház´ı na ˇradu grafické vyjádˇren´ı architektury této platformy tak, aby bylo zˇrejmé, jaké fyzické celky obsahuje a jak by mˇely být uspoˇrádány.

3.5.1 Fyzick´ a architektura platformy

Na obrázku 3.4 je zachycena fyzická architektura platformy. Je zde patrné, ˇze veˇskeré jej´ı komponenty jsou pˇripojeny do m´ıstn´ı (LAN) ˇci veˇrejné (WAN) s´ıtˇe. T´ım je naznaˇceno, ˇze tato platforma nutnˇe nemus´ı být um´ıstˇena v jedné lokalitˇe, nýbrˇz lze jednotlivé komponenty dislokovat i do jiných lokalit. To je umoˇznˇeno jednak zp˚usobem komunikace, kde vˇsechny komponenty spolu komunikuj´ı prostˇrednictv´ım TCP/IP protokolu a za druhé skuteˇcnost´ı, ˇze je takto platforma navrˇzená. Kom- ponentami typu server zde zobrazenými jsou: aplikaˇcn´ı server (AS), databázový server (DB), výpoˇcetn´ı server (EXE), poskytovatel identit (IdP). Komponenta editoru (ED) je pro tyto úˇcely zaˇrazena sp´ıˇse do kategorie klientských aplikac´ı, pˇrestoˇze je jako webová aplikace hostována na webovém serveru. A posledn´ı komponentou,

(23)

pro tento okamˇzik rovnˇeˇz typu klientské aplikace, je import (IMP). Pod kaˇzdou z komponent je uvedeno jej´ı minimáln´ı vs maximáln´ı zastoupen´ı v rámci platformy. Na obrázku maj´ı komponenty vyznaˇceno zastoupen´ı formátu 1:N, coˇz zna- mená, ˇze kaˇzdá z komponent tam bude minimálnˇe jednou. Pro demonstraˇcn´ı úˇcely a ovˇeˇren´ı funkˇcnosti je takovéto zastoupen´ı vhodné. Pro praktické vyuˇzit´ı by bylo moˇzné nalézt i jiné hodnoty. Pokud by kupˇr´ıkladu bylo dopˇredu známo, ˇze platforma nepotˇrebuje importovat data z extern´ıch systém˚u, pak by logicky tato komponenta nebyla zastoupena. Na druhé stranˇe je ale zjevné, ˇze se zde vyskytuj´ı i komponenty, u nichˇz takováto diskuze postrádá smysl, jelikoˇz bez nich by platforma nebyla funkˇcn´ı. V tomto smyslu by se mohlo jednat o aplikaˇcn´ı a databázový server, pˇr´ıpadnˇe pak o poskytovatele identit a výpoˇcetn´ı server.

Obr´azek 3.4: Fyzick´a architektura platformy

3.5.2 Platforma jako SaaS

Pro úˇcely provozn´ıho prostˇred´ı je jeˇstˇe vhodné vzpomenout pasáˇz, která v kapitole 3.2 pojednává o moˇznosti provozovat poskytovateli platformu modelem SaaS.

SaaS (software as a service ˇci ˇcesky software jako sluˇzba) je model nasazen´ı softwaru, kdy docház´ı k hostován´ı aplikace provozovatelem sluˇzby. Sluˇzba je dále nab´ızena uˇzivatel˚um pˇres Internet. Uˇzivatel je tak oproˇstˇen od kupován´ı softwaru ˇci hardwaru, instalaci, konfiguraci a provozu technologi´ı jako takových. SaaS vznikla jako reakce na potˇrebu sniˇzován´ı náklad˚u na software, rychlého nasazen´ı a out- sourcingu. Nasazen´ım SaaS odpadaj´ı investice do aplikaˇcn´ıho softwarového bal´ıku.

(24)

Zákazn´ık jednoduˇse vyuˇz´ıvá softwarovou funkcionalitu na dálku jako sluˇzbu. Zákazn´ık plat´ı jenom provozn´ı náklady. [3]

U tohoto modelu je moˇzné nam´ıtnout, ˇze t´ım uˇzivatel m˚uˇze ztratit kontrolu nad svými daty, protoˇze je de facto svˇeˇruje tˇret´ı stranˇe. Zde záleˇz´ı, jakým zp˚usobem provozovatel dále chrán´ı data uˇzivatel˚u. V dneˇsn´ı dobˇe, kdy si i velké nadnárodn´ı technologické firmy jsou tohoto problému vˇedomy a kdy existuje velké mnoˇzstv´ı zp˚usob˚u zabezpeˇcen´ı dat, se ukazuje, ˇze to nen´ı problém technický. V tomto kontextu je nadále zabezpeˇcen´ı dat touto prac´ı navrhovanou platformou uvaˇzováno a je popsáno u jednotlivých komponent v následuj´ıc´ıch kapitolách.

3.6 Metodiky v´ yvoje softwaru

Vývoj softwaru procház´ı od svého vzniku zmˇenami. Smyslem metodik pro jeho vývoj je stanoven´ı postup˚u a zp˚usob˚u, jak takový software vhodnˇe vyv´ıjet. Avˇsak i zde plat´ı, ˇze sebelepˇs´ı metodika nemus´ı vyhovovat vˇsem pˇr´ıpad˚um ˇci vývojáˇr˚um. Proto je smyslem této kapitoly poukázat na nˇekteré významné existuj´ıc´ı metodiky.

Následuj´ıc´ı metodiky se ˇrad´ı do kategorie tzv. modelu ˇzivotn´ıho cyklu. Tedy pomoc´ı modelu je definována posloupnost jednotlivých etap vývoje bez stanoven´ı metody, pomoc´ı které se boudou etapy realizovat.

Model programuj a opravuj je nejprimitivnˇejˇs´ı model vývoje softwaru. Jedná se o jednoduchý zp˚usob vývoje, jeˇz je zaloˇzen na opakuj´ıc´ıch se ˇcinnostech pro- gramován´ı, testován´ı a opravˇe chyb. V prvn´ı etapˇe jsou specifikovány poˇzadavky, následnˇe se pˇristupuje k opakuj´ıc´ımu se cyklu kódován´ı a opravován´ı.

Vodopádový model je sekvenˇcn´ı vývojový proces, ve kterém lze pˇrirovnat vývoj k neustále se svaˇzuj´ıc´ımu toku. Základn´ımi fázemi jsou: analýza poˇzadavk˚u, návrh, implementace, testován´ı, a integrace. Projekt se organizuje do fáz´ı, které se ˇrad´ı postupnˇe za sebou. ˇCasto bývá v praxi doprovázen aˇz formáln´ı administrativou, která dokumentuje zmˇeny poˇzadavk˚u, jejich schválen´ı, atp. Nevýhodou m˚uˇze být, ˇze testován´ı prob´ıhá po ukonˇcen´ı vývoje a tud´ıˇz má v principu pouze potvrdit správnost vyvinutého softwaru. [6]

Spirálový model byl definován Barry Bohem v roce 1985. Tento model ˇzivotn´ıho cyklu klade pˇredevˇs´ım velký d˚uraz na analýzu rizik. Model rozdˇeluje projekt do jed- notlivých krok˚u. V kaˇzdé iteraci se provádˇej´ı následuj´ıc´ı fáze: stanoven´ı c´ıl˚u, analýza rizik, návrh ˇreˇsen´ı, vývoj, testován´ı a plánován´ı. Zde, na rozd´ıl od vodopádového modelu, jsou výstupy po dokonˇcen´ı kaˇzdé iterace pˇredávány ve formˇe prototypu, kterým si zákazn´ık m˚uˇze snáze ovˇeˇrit, ˇze se vývoj ub´ırá správným smˇerem. Výhodou je sn´ıˇzen´ı náklad˚u na vývoj softwaru t´ım, ˇze jsou vˇcas odhalovány chyby. [6]

Dalˇs´ı kategori´ı jsou pak metodiky zaloˇzené na objektovém pˇr´ıstupu, které nahl´ıˇzej´ı na data a funkce jako na souˇcást objektu. T´ım se snaˇz´ı prostˇrednictv´ım pˇredepsaných model˚u d˚uvˇeryhodnˇeji zachytit modelovanou realitu.

Rational Unified Process (RUP) pˇredstavuje proces, který vyuˇz´ıvá pˇr´ıstup k vývoji softwaru za pomoci ˇrad nástroj˚u, ˇsablon, artefakt˚u a vˇcasných dodávek prototyp˚u. Od ostatn´ıch výˇse zm´ınˇených pˇr´ıstup˚u se pˇreváˇznˇe liˇs´ı t´ım, ˇze se jedná o rozsáhlou a detailnˇeji propracovanou metodiku. Metodika RUP je vhodná primárnˇe

(25)

na velké projekty, nicménˇe je moˇzné ji upravovat i pro jednoduˇsˇs´ı projekty. Vývoj prob´ıhá v iterativn´ıch cyklech, kde kaˇzdá iterace má podobu menˇs´ıho vodopádu, tj.

obsahuje vˇsechny fáze tohoto modelu (analýza – testován´ı). Na poˇcátku projektu je nejv´ıce ˇcasu vˇenováno specifikaci poˇzadavk˚u. Pozdˇejˇs´ı iterace vývoje se zamˇeˇruj´ı na implementaci a testován´ı. Výsledkem kaˇzdého cyklu je nová verze produktu. [5]

Neménˇe zaj´ımavou skupinu tvoˇr´ı agiln´ı metodiky. To jsou metodiky zaloˇzené na vývoji softwaru na iterativn´ım a inkrementáln´ım pˇr´ıstupu. Umoˇzˇnuj´ı rychlý vývoj softwaru a zároveˇn dokáˇz´ı reagovat na zmˇenu poˇzadavk˚u v pr˚ubˇehu vývojového cyklu. Podle tˇechto metodik se správnost systému ovˇeˇr´ı jedinˇe pomoc´ı rychlého vývoje, pˇredloˇzen´ı zákazn´ıkovi a následných úprav dle zpˇetné vazby. Pomˇernˇe novým a známým zástupcem této kategorie je Scrum (viz [7]) ˇci Extrémn´ı programován´ı (viz [8]).

Do jisté m´ıry odliˇsným zp˚usobem pˇr´ıstupu k vývoji se následuj´ıc´ı technika vývoje liˇs´ı od pˇredchoz´ıch. Pˇredchoz´ı zp˚usoby vývoje se zamˇeˇrovaly na situaci, kdy byl kód programu napsán a bylo tˇreba jej otestovat. Avˇsak existuje i opaˇcný pˇr´ıstup, kdy je nejprve napsán test pro urˇcitou ˇcást programu a ta je aˇz následnˇe vytvoˇrena. Tento pˇr´ıstup se nazývá TDD (Test-driven development ˇci ˇcesky programován´ı ˇr´ızené testy). Jeho smyslem je v prvé ˇradˇe tvorba test˚u a aˇz následnˇe vývoj. Samotná tvorba test˚u je samozˇrejmˇe zaloˇzena na dostupných technikách testován´ı uvedených v následuj´ıc´ı kapitole.

Vzhledem k povaze této diplomové práce a skuteˇcnosti, ˇze na vývoji se v souˇcasné dobˇe pod´ıl´ı pouze jeden ˇclovˇek, tedy autor, je nasnadˇe, ˇze se vývoj bl´ıˇz´ı vodopádovému modelu.

3.7 Techniky testov´ an´ı softwaru

Stejnˇe jako v pˇredchoz´ı kapitole existuje ˇrada metodik, tak i zde existuje v´ıce pohled˚u a zp˚usob˚u dˇelen´ı, jak software testovat. Z pˇredchoz´ı kapitoly je patrné, ˇze tematika testován´ı byla souˇcást´ı pˇrinejmenˇs´ım vˇetˇsiny uvedených metodik. I kdyˇz u nˇekterých se mohlo jednat sp´ıˇse o formáln´ı stránku vˇeci, u nˇekterých byla pouˇzita v pravém slova smyslu a ulehˇcila vývoj.

Prvn´ım pohledem na testov´an´ı je pohled pomoc´ı zp˚usobu proveden´ı testu.

Nejjednoduˇsˇs´ı je metoda pomoc´ı ˇcerné a b´ılé skˇr´ıˇnky. Testován´ı ˇcerné skˇr´ıˇnky je zaloˇzeno na myˇslence, ˇze tester nen´ı seznámen s vnitˇrn´ı logikou testovaného softwaru.

Poté tedy testován´ı prob´ıhá sledován´ım vstup˚u a výstup˚u, kdy se kontroluje, zda je na výstupu produkován oˇcekávaný výsledek. Pˇri testován´ı b´ılé skˇr´ıˇnky tester zná obsah zdrojových kód˚u a má moˇznost tak otestovat vˇsechny situace, na které je daný software pˇripraven. To m˚uˇze být v nˇekterých situac´ıch kontraproduktivn´ı, jelikoˇz mu m˚uˇze uniknout nˇejaká podm´ınka, na kterou ani vývojáˇr nepomyslel. V tom pˇr´ıpadˇe je výsledek takového testu nepˇresný. Dalˇs´ı moˇznost rozdˇelen´ı technik testován´ı je manuáln´ı a automatizované testován´ı. Rozd´ıl spoˇc´ıvá v tom, ˇze pˇri manuáln´ım testován´ı testuje ˇclovˇek, zat´ımco pˇri automatizovaném testován´ı za nˇeho testuje software. Posledn´ı v této kategorii je testován´ı splnˇen´ım a selhán´ım. Testován´ı splnˇen´ım pˇri zaˇcátku programu nejprve otestuje jeho elementárn´ı funkˇcnost. Pokud

(26)

program toto spln´ı, pak t´ımto testem projde. Úˇcelem nen´ı pokouˇset se odhalit jeho slabá m´ısta. Jedná se sp´ıˇse o simulaci bˇeˇzného pouˇzit´ı systému. Naopak test selhán´ım se provede aˇz tehdy, kdyˇz je zabezpeˇcena elementárn´ı funkˇcnost. V této fázi jiˇz testujeme neobvyklé testové pˇr´ıpady, stabilitu systému atd. [4]

Dalˇs´ım pohledem na testován´ı je rozdˇelen´ı podle úrovnˇe vývoje, ˇc´ımˇz je myˇsleno v jaké úrovni se nacház´ı samotný testovaný objekt. Prvn´ım zástupcem této kategorie a téˇz zástupce na nejniˇzˇs´ı úrovni je testován´ı programátorem. Programátor po vytvoˇren´ı programového kódu sv˚uj kód ihned ovˇeˇr´ı. V praxi si vˇsak programátor netestuje svoji ˇcást kódu, ale realizuje se tzv. test ˇctyˇr oˇc´ı. Coˇz je situace, kdy kód otestuje jiný programátor neˇz ten, který jej vytvoˇril. Program je v tomto stupni kon- trolován na úrovni zdrojového kódu. Dalˇs´ım zástupcem je jednotkové testován´ı.

T´ım je myˇsleno testován´ı jednotlivých metod a funkc´ı daných objekt˚u. Testovanou jednotkou je samostatnˇe testovatelná ˇcást aplikaˇcn´ıho programu. Testy tˇechto jed- notek se zapisuj´ı ve formˇe programového kódu. V dobˇe, kdy je vývojáˇr hotov se svými testy, pˇricház´ı na ˇradu testovac´ı tým. Integraˇcn´ı testy nepˇripravuje programátor, ale pˇredevˇs´ım onen tým. Mus´ı být ovˇeˇrena bezchybná komunikace mezi jednotlivými komponentami uvnitˇr aplikace. Integraci lze ovˇeˇrovat nejen mezi komponentami, ale také mezi komponentou a operaˇcn´ım systémem, hardwarem ˇci rozhran´ım r˚uzných systém˚u. V této fázi se testuje integrace dosud jednotlivˇe ovˇeˇrených ˇcást´ı. Po proveden´ı integraˇcn´ıch test˚u pˇricház´ı na ˇradu systémové testován´ı. Bˇehem tˇechto test˚u je aplikace ovˇeˇrována jako funkˇcn´ı celek. Z toho tedy vyplývá, ˇze se jedná o testován´ı aˇz v pozdˇejˇs´ı fázi projektu. Tyto testy ovˇeˇruj´ı aplikaci z pohledu zákazn´ıka. Na pˇripravených scénáˇr´ıch se simuluj´ı r˚uzné kroky, které v praxi mohou nastat. Obvykle prob´ıhaj´ı v nˇekolika kolech. Nalezené chyby jsou opraveny a v dalˇs´ıch kolech jsou tyto opravy opˇet otestovány. Tyto testy jsou posledn´ı fáz´ı, po které bude produkt pˇredán zákazn´ıkovi. Tato úroveˇn test˚u tak vˇetˇsinou slouˇz´ı jako výstupn´ı kontrola softwaru.

Systémové testován´ı je obsaˇzeno prakticky v kaˇzdém procesu testován´ı. Bez této

´

urovnˇe by celé testován´ı softwaru nemˇelo ˇzádný význam. V okamˇziku, kdy zákazn´ık pˇrevezme software, mˇel by jej podrobit akceptaˇcn´ımu testován´ı. To je provádˇeno podle pˇripravených scénáˇr˚u, které spoleˇcnˇe pˇripravil zákazn´ık s dodavatelem. Testy prob´ıhaj´ı na testovac´ım prostˇred´ı u zákazn´ıka. Nalezené nesrovnalosti mezi aplikac´ı a specifikac´ı jsou odeslány zpˇet vývojovému týmu, který provede jejich opravu. [9]

Zp˚usob testován´ı jednotlivých komponent v rámci platformy je u kaˇzdé komponenty bl´ıˇze popsán v pˇr´ısluˇsných kapitolách.

3.8 Licence a dostupnost

Veˇskeré kódy, skripty, programy aj. jsou vydány pod licenc´ı MIT. Výhodou této licence je, ˇze neomezuje pouˇzit´ı takto licencovaného d´ıla, pouze vyˇzaduje, aby byl text licence dále distribuován spolu s d´ılem, at’ uˇz jakkoli modifikovaným. Zdrojové kódy platformy jsou volnˇe dostupné v GIT repozitáˇr´ıch (viz [10]). Repozitáˇre zaˇc´ınaj´ı prefixem cpdn-*, kdy m´ısto hvˇezdiˇcky je uveden název jednotlivé komponenty.

(27)

4 Poskytovatel identity

V rámci kapitoly 3.1 byly jako jedny z prvn´ıch poˇzadavk˚u vzneseny ty smˇerem k identifikaci uˇzivatele, jeho identitˇe a zp˚usobu jej´ıho ovˇeˇren´ı. K platformˇe sm´ı pˇristupovat pouze ovˇeˇrený uˇzivatel. Proto je nejprve nutné provést jeho ovˇeˇren´ı.

Tato problematika v sobˇe ukrývá tˇri základn´ı okruhy – identitu uˇzivatele, zp˚usob jej´ıho ovˇeˇren´ı (autentizace) a udˇelen´ı oprávnˇen´ı na základˇe identity (autorizace).

Bylo by moˇzné pouˇz´ıt jiˇz plnˇe funkˇcn´ı systémy, které poskytuj´ı SSO, tedy tzv.

Single Sign On, coˇz lze pˇreloˇzit jako jediné pˇrihláˇsen´ı na webu. T´ım je myˇsleno, ˇze uˇzivatel se v rámci svého domovského poskytovatele identit autentizuje a ten mu následnˇe vydá povˇeˇren´ı, se kterým m˚uˇze pracovat v aplikaci tˇret´ı strany pod svoj´ı identitou. Typickým zástupcem, a nejen v akademické obci, je projekt s názvem Shibboleth. Mohlo by se tedy zdát, ˇze by bylo moˇzné jej vyuˇz´ıt. To by beze sporu na urˇcité ˇcásti platformy bylo moˇzné. Nicménˇe z hlediska toho, jak byla platforma navrˇzena v kapitole 3.3, se zde nacház´ı vhodnˇejˇs´ı varianta vlastn´ı implementace autentizaˇcn´ıho procesu a následné pouˇzit´ı protokolu OAuth 2.0 jako autorizaˇcn´ıho procesu. Toto spojen´ı je vhodnˇejˇs´ı zejména z toho d˚uvodu, ˇze je pˇr´ımo navrˇzeno k zabezpeˇcen´ı a ˇr´ızen´ı pˇr´ıstupu aplikaˇcn´ıho serveru jako poskytovatele webových sluˇzeb, coˇz je pˇresnˇe závˇer výˇse citované kapitoly.

4.1 Identita uˇ zivatele

Identita uˇzivatele je soubor informac´ı, kter´e popisuj´ı atributy uˇzivatele jako osoby.

Ty by v kontextu této platformy mˇely obsahovat základn´ı údaje, jakými jsou jméno, pˇr´ıjmen´ı, kontakt na osobu aj. Tyto údaje by mˇely v rámci celé platformy slouˇzit jako tzv. profil uˇzivatele ˇci profil uˇzivatelovi identity. Profil je identifikován napˇr´ıˇc vˇsemi profily unikátn´ım kódem, kterým je uˇzivatel˚uv email. Principiálnˇe by to mohl být i napˇr. nˇejaký náhodnˇe generovaný ˇretˇezec nebo ˇc´ıslo. Z praktického hlediska vˇsak byl zvolen email. Je zcela na m´ıstˇe konstatován´ı, ˇze v rámci tohoto uspoˇrádán´ı by duplicitn´ı záznamy nebyly vhodné.

V rámci identity daného uˇzivatele by bylo moˇzné jeˇstˇe uvaˇzovat rozˇs´ıˇren´ı o jeho zaˇclenˇen´ı do skupiny uˇzivatel˚u. To by bylo vhodné zejména pro situaci, kdy by s platformou pracovali uˇzivatelé jednotlivých oddˇelen´ı ˇci spoleˇcnost´ı. Byt’ toto rozˇs´ıˇren´ı nen´ı stˇeˇzejn´ım bodem této práce, je s n´ım alespoˇn uvaˇzováno pro pˇr´ıpad, aby takováto moˇznost mohla být v budoucnu implementována. Dalˇs´ım rozˇs´ıˇren´ım v tomto smˇeru by mohla být správa jednotlivých skupin.

Naopak stˇeˇzejn´ı ˇc´ast´ı spojenou s identitou uˇzivatele, ˇcili s jeho profilem, je

(28)

pˇr´ıstupový úˇcet. Tento pˇr´ıstupový úˇcet slouˇz´ı pro ovˇeˇren´ı, ˇze k platformˇe pˇristupuje právˇe ten uˇzivatel, který zná svoji identitu a údaje pro jej´ı ovˇeˇren´ı, tedy pˇr´ıstupové

´

udaje svého pˇr´ıstupového úˇctu. Tento úˇcet nazvˇeme jako hlavn´ı pˇr´ıstupový úˇcet.

Nad t´ımto úˇctem m˚uˇze být zˇr´ızeno monitorován´ı, které dokáˇze ovlivnit politiku pˇr´ıstupu. Monitoring lze provádˇet u kaˇzdého takového úˇctu, kdy lze uchovávat parametry jako ˇcas pˇr´ıstupu, poˇcet úspˇeˇsných/neúspˇeˇsných pokus˚u o pˇr´ıstup, z jaké IP adresy byl pˇr´ıstup proveden atd. Následnˇe na základˇe tˇechto informac´ı m˚uˇze být provedeno vyhodnocen´ı, které m˚uˇze ovlivnit politiku pˇr´ıstupu.

V pˇr´ıloze A je pˇriloˇzen ER diagram databáze pro uchováván´ı identit uˇzivatel˚u a s nimi spojených pˇr´ıstupových úˇct˚u. Mezi hlavn´ı entity patˇr´ı entita Profile, která spolu s entitou Contact uchovává atributy uˇzivatele a vytváˇr´ı tak jeho identitu v rámci platformy. Druhou významnou entitou je Account, která spravuje hlavn´ı pˇr´ıstupové úˇcty. V této entitˇe je základn´ım atributem email a heslo. Uˇzivateli je na základˇe jejich znalosti umoˇznˇen pˇr´ıstup k dalˇs´ım krok˚um ovˇeˇren´ı a udˇelen´ı oprávnˇen´ı k pˇr´ıstupu. Dále jsou zde uvedeny entity souvisej´ıc´ı se zm´ınˇenou podporou organi- zace uˇzivatel˚u do skupin ˇci pro monitorován´ı pokus˚u o pˇr´ıstup.

4.2 Autentizace

Autentizace je bezpeˇcnostn´ı opatˇren´ı, které zajiˇst’uje ochranu pˇred falˇsován´ım identity, kdy se subjekt vydává za nˇekoho, kým nen´ı. Lze rozliˇsit autentizaci osoby ˇci autentizaci zprávy. Pro potˇreby platformy se uvaˇzuje prvn´ı moˇznost. Pˇri pˇr´ıstupu k n´ı je potˇreba ovˇeˇrit proklamovanou identitu pˇristupuj´ıc´ıho uˇzivatele. Pokud ovˇeˇren´ı dopadne ve výsledku kladnˇe, lze konstatovat, ˇze pˇristupuj´ıc´ı uˇzivatel je t´ım, kdo ve skuteˇcnosti je. I zde m˚uˇze samozˇrejmˇe nastat situace, kdy se podaˇr´ı nˇejakému

´

utoˇcn´ıkovi ukr´ast identitu skuteˇcn´eho uˇzivatele.

Vzhledem k závˇeru z kapitoly 3.3, kde bylo konstatováno, ˇze komponenta poskytovatele identit m˚uˇze být vytvoˇrena jako webová aplikace, se nab´ız´ı následuj´ıc´ı postup. Autentizace zapoˇcne ve formuláˇri na webové stránce, na kterou uˇzivatel pˇristoupil. Po vyplnˇen´ı tohoto formuláˇre, jehoˇz obsahem je pole pro email a heslo, coˇz jsou mimo jiné kl´ıˇcové identifikaˇcn´ı znaky hlavn´ıho pˇr´ıstupového úˇctu, se for- muláˇr odeˇsle na server. Vyhodnocen´ı spoˇc´ıvá ve vyhledán´ı odpov´ıdaj´ıc´ıho hlavn´ıho pˇr´ıstupového úˇctu a následnˇe ovˇeˇren´ı správnosti zadaného hesla. Pokud operace probˇehne kladnˇe, tedy je nalezen pˇr´ısluˇsný hlavn´ı pˇr´ıstupový úˇcet a bylo zadáno správné heslo, pak je uˇzivatel pˇresmˇerován na dalˇs´ı krok k z´ıskán´ı pˇr´ıstupu do platformy, a to autorizaci. Ta je popsána v následuj´ıc´ı kapitole.

4.3 Autorizace

Autorizace je proces z´ısk´an´ı opr´avnˇen´ı k proveden´ı operace ˇci pˇr´ıstupu ke zdroj˚um.

Také se tak oznaˇcuje ono vlastn´ı oprávnˇen´ı, at’ je ve formˇe napˇr. náhodného ˇretˇezce urˇcité délky, ˇci logické hodnoty. Zpravidla se pˇred autorizac´ı jeˇstˇe provád´ı proces ovˇeˇren´ı identity uˇzivatele, který ˇzádá o autorizaci. T´ım je myˇslena autentizace.

(29)

4.3.1 OAuth 2.0

V okamˇziku, kdy je uˇzivatel autentizován, pˇricház´ı na ˇradu vytvoˇren´ı oprávnˇen´ı, které mu zajist´ı následný pˇr´ıstup ke zdroj˚um platformy. To lze uˇcinit pouˇzit´ım protokolu OAuth 2.0, coˇz je modern´ı autorizaˇcn´ı protokol, který se stal de facto standardem pro zabezpeˇcen´ı webových sluˇzeb (viz [11]). Jeho hlavn´ı výhoda tkv´ı v tom, ˇze uˇzivatel m˚uˇze poskytnout klientské aplikaci pˇr´ıstup ke zdroj˚um poskytovatele, aniˇz by té aplikaci musel vyzradit své pˇr´ıstupové údaje, a t´ım ji poskytl prakticky neomezený pˇr´ıstup k jeho úˇctu. Dále umoˇzˇnuje vymezit pravomoci jed- notlivých klientských aplikac´ı a sledovat vyuˇz´ıván´ı poskytnutých privilegi´ı. Klientská aplikace se m˚uˇze autentizovat jak sama za sebe, tak i za jej´ıho uˇzivatele, který k tomu vydá explicitn´ı souhlas. D´ıky tomu lze, bez rizika naruˇsen´ı ochrany osobn´ıch údaj˚u, umoˇznit pˇr´ıstup k chránˇeným dat˚um uˇzivatel˚u, ke kterým jim dá jejich uˇzivatel explicitn´ı souhlas. Dalˇs´ı výhoda spoˇc´ıvá v jeho snadné implementaci.

Protokol OAuth 2.0 specifikuje 4 z´akladn´ı role (viz [11]). Tˇemi jsou:

• majitel zdroje, kter´y ud´ıl´ı pˇr´ıstup ke zdroji (typicky uˇzivatel),

• poskytovatel zdroje, coˇz je server, na kterém jsou zdroje uloˇzeny a ze kterého jsou pak následnˇe z´ıskávány,

• klient, coˇz je aplikace, prostˇrednictv´ım které uˇzivatel zadal poˇzadavek vedouc´ı k z´ıskán´ı nˇejakého chránˇeného zdroje,

• autorizaˇcn´ı server, který vydává pˇr´ıstupové kódy klient˚um po úspˇeˇsné autentizaci a autorizaci.

Dále jsou definovány 4 typy udˇelen´ı autorizaˇcn´ıho oprávnˇen´ı (viz [11]). Jedná se vlastnˇe o postupy, nebo o proces, jak vydat samotné oprávnˇen´ı. Jsou jimi:

• povˇeˇren´ı klienta, které se pouˇz´ıvá pˇreváˇznˇe v situaci, kdy klient je zároveˇn majitelem zdroje; u tohoto oprávnˇen´ı v rámci webových SPA vzniká problém prozrazen´ı pouˇzitého identifikátoru klienta a hesla pˇri autorizaˇcn´ım poˇzadavku klienta, protoˇze zdrojový kód klienta psaný v jazyce JavaScript je ˇcitelný bˇeˇznému uˇzivateli,

• povˇeˇren´ı uˇzivatele je nadstavbou pˇredchoz´ıho, protoˇze umoˇzˇnuje zadat iden- tifikátor uˇzivatele a jeho hesla aˇz za bˇehu programu, tud´ıˇz zde nehroz´ı nebezpeˇc´ı prozrazen´ı tˇechto údaj˚u z pohledu napsaného kódu aplikace jako v pˇredchoz´ım pˇr´ıpadˇe,

• autorizaˇcn´ı kód je oprávnˇen´ı nejv´ıce pouˇz´ıvané ve spojen´ı s t´ımto protokolem, jelikoˇz postup jeho z´ıskán´ı spoˇc´ıvá v nˇekolika kroc´ıch nav´ıc oproti pˇredchoz´ım typ˚um a jelikoˇz se jedná v tomto smyslu o nejuniverzálnˇejˇs´ı ˇreˇsen´ı ze zde zm´ınˇených pro autorizace pˇr´ıstupu k aplikac´ım tˇret´ıch stran,

• implicitn´ı povˇeˇren´ı, které vycház´ı z autorizaˇcn´ıho kódu, ale je zjednoduˇseno t´ım, ˇze nevyˇzaduje ukládán´ı identifikátoru klienta a jeho hesla; vhodné pro webové ˇci jiné aplikace, kde jsou volnˇe dostupné zdrojové kódy ve kterých by byly ony údaje zjistitelné.

(30)

4.3.2 Pouˇ zit´ e zp˚ usoby autorizace

S protokolem OAuth 2.0 souvis´ı jeˇstˇe jeden pojem, který je nutné v rámci této práce zavést. T´ım pojmem je úˇcelový pˇr´ıstupový úˇcet. Tento typ je druhým typem pˇr´ıstupového úˇctu v rámci platformy vedle jiˇz dˇr´ıve definovaného hlavn´ıho pˇr´ıstupového úˇctu. Smyslem tohoto druhého úˇctu je umoˇznit pˇr´ıstup aplikaci ke sluˇzbám aplikaˇcn´ıho serveru i za pomoci jiných pˇr´ıstupových údaj˚u, neˇz které pouˇz´ıvá hlavn´ı pˇr´ıstupový úˇcet. To je vhodné zejména v situaci, kdy je poˇzadováno omezen´ı oprávnˇen´ı ˇci výhradnˇe úˇcelovˇe zˇr´ızený pˇr´ıstup pro konkrétn´ı aplikaci pod identitou uˇzivatele. Identita uˇzivatele je pouze jedna. Ale moˇznost´ı pˇr´ıstupu m˚uˇze být v´ıce.

Toho je dosaˇzeno právˇe kv˚uli zaveden´ı úˇcelového pˇr´ıstupového úˇctu, jelikoˇz poˇcet tˇechto úˇct˚u v rámci jedné identity uˇzivatele nen´ı omezen. Tento pˇr´ıstup je demon- strovaný na následuj´ıc´ım obrázku.

Obr´azek 4.1: OAuth – postup Povˇeˇren´ı uˇzivatele

Na obrázku 4.1 je znázornˇen postup z´ıskán´ı pˇr´ıstupového kódu pomoc´ı postupu povˇeˇren´ı uˇzivatele. Klient je v tomto pˇr´ıpadˇe aplikace, která potˇrebuje autorizovat sv˚uj pˇr´ıstup, aby mohla komunikovat s aplikaˇcn´ım serverem. Nejprve proto odeˇsle na autorizaˇcn´ı server (OAuth server) autorizaˇcn´ı poˇzadavek. Jeho souˇcást´ı jsou údaje pˇr´ısluˇsné úˇcelovému pˇr´ıstupovému úˇctu, který je registrován pro pouˇzit´ı s t´ımto klientem. Autorizaˇcn´ı server odpov´ı na poˇzadavek pˇr´ıstupovým kódem, samozˇrejmˇe pro platná data úˇcelového pˇr´ıstupového úˇctu zaslaná v poˇzadavku, který poté klient pouˇz´ıvá k pˇr´ıstupu na aplikaˇcn´ı server.

Na následuj´ıc´ım obrázku 4.2 je znázornˇen postup z´ıskán´ı pˇr´ıstupového kódu pomoc´ı postupu autorizaˇcn´ıho kódu. Na prvn´ı pohled je vidˇet, ˇze se jedná o sloˇzitˇejˇs´ı proces, jelikoˇz se tam provád´ı v´ıce poˇzadavk˚u a odpovˇed´ı. Klient nejprve odeˇsle autorizaˇcn´ı poˇzadavek na autorizaˇcn´ı server. Ten jeho poˇzadavek pˇresmˇeruje dále na autentizaˇcn´ı server, protoˇze daný uˇzivatel nen´ı autentizován. Z principu funkce

(31)

samotného autorizaˇcn´ıho serveru, kdy ten neprovád´ı ovˇeˇren´ı identity, mus´ı poˇzadavek pˇredat dále. Autentizaˇcn´ı server poskytovatele identit je d˚uvˇeryhodnou stranou, které uˇzivatel sdˇel´ı své údaje hlavn´ıho pˇr´ıstupového úˇctu. Pokud ovˇeˇren´ı probˇehne korektnˇe a uˇzivatel je t´ımto autentizován, pˇrejde se k dalˇs´ımu kroku, kterým je zobrazen´ı ˇzádosti o potvrzen´ı pˇr´ıstupu. Pokud uˇzivatel vyjádˇr´ı souhlas, povol´ı t´ım pˇr´ıstup klienta k jeho dat˚um prostˇrednictv´ım aplikaˇcn´ıho serveru. Klientovi se pak pˇres autorizaˇcn´ı server vrát´ı zpˇet autorizaˇcn´ı kód. Tento kód slouˇz´ı jednak jako potvrzen´ı, ˇze uˇzivatel povolil klientovi pˇr´ıstup, ale také k výmˇenˇe tohoto kódu za kód pˇr´ıstupový. Poté následuje výmˇena autorizaˇcn´ıho kódu za pˇr´ıstupový kód mezi klientem a autorizaˇcn´ım serverem. Po jej´ım úspˇeˇsném dokonˇcen´ı má jiˇz klient validn´ı pˇr´ıstupový kód pro pˇr´ıstup na aplikaˇcn´ı server.

Obr´azek 4.2: OAuth – postup Autorizaˇcn´ım k´odem

Z pˇredchoz´ıch dvou obrázk˚u je zˇretelnˇe poznat, v ˇcem se jednotlivé pˇr´ıstupy liˇs´ı a proˇc jsou pro dané situace vhodné. V rámci vytváˇrené platformy je prvn´ı postup (povˇeˇren´ı uˇzivatele) vhodné pouˇz´ıt do komponent importu dat a provádˇen´ı výpoˇct˚u. A to vzhledem k tomu, ˇze tyto aplikace jsou navrˇzeny jako terminálové a nemaj´ı pˇr´ıstup ke GUI autentizaˇcn´ıho a autorizaˇcn´ıho serveru prostˇrednictv´ım webového prohl´ıˇzeˇce. Na druhé stranˇe pro komponentu editor je pouˇzitelný druhý postup (autorizaˇcn´ı kód). Je nutné si na tomto m´ıstˇe uvˇedomit, ˇze i pˇri pouˇzit´ı rozd´ılných postup˚u autorizace je vˇse zaloˇzeno na spoleˇcném základu a jedná se stále o jeden protokol, který nab´ız´ı takovéto moˇznosti. A právˇe to je moˇzné vyzdvihnout jako jeho pˇrednost v˚uˇci jiným ˇreˇsen´ım.

(32)

4.4 Implementace

Souˇcást´ı této komponenty je správa identit, autentizaˇcn´ı server i autorizaˇcn´ı server.

Celá komponenta je postavena na frameworku Phalcon PHP ve verzi 2.0.9. Imple- mentace správy identit byla ˇreˇsena pouze do úrovnˇe funkˇcn´ıho databázového modelu (viz pˇr´ıloha A), kdy si z této databáze autentizaˇcn´ı server pˇreb´ırá potˇrebné údaje o identitˇe a hlavn´ım pˇr´ıstupovém úˇctu. Autentizaˇcn´ı server je souˇcást´ı komponenty a je vytvoˇren jako aplikace za pouˇzit´ı modelu MVC. V této ˇcásti je implentován proces ovˇeˇren´ı identity uˇzivatele na základˇe zadaných údaj˚u hlavn´ıho pˇr´ıstupového

´

uˇctu (emailu a hesla). To vˇse samozˇrejmˇe graficky pomoc´ı webov´eho GUI.

Posledn´ıˇcást´ı této komponenty je pak autorizaˇcn´ı server. Vzhledem ke skuteˇcnosti, ˇze zámˇerem této práce nebylo takový server tvoˇrit, tak byl pouˇzit volnˇe dostupný OAuth 2.0 Server PHP (viz [12]), který je ˇs´ıˇren pod licenc´ı MIT. Tento server samozˇrejmˇe podporuje výˇse rozeb´ırané postupy, tud´ıˇz jej staˇcilo správnˇe nastavit a integrovat do projektu jako sluˇzbu.

Výstupem implementace je tedy webová aplikace psaná objektovým pˇr´ıstupem s návrhovým vzorem MVC v jazyce PHP, která je hostována na webovém serveru s podporou bˇehu PHP skript˚u.

4.5 Testov´ an´ı

Testován´ı této komponenty prob´ıhalo za pomoc´ı následuj´ıc´ıch technik. Po vytvoˇren´ı daného kódu byl tento kód testován programátorem. Vzhledem k faktu, ˇze se zde vyuˇz´ıval extern´ı projekt implementuj´ıc´ı protokol OAuth a vytváˇrej´ıc´ı autorizaˇcn´ı server, a jeho vývojáˇri provádˇeli pˇred jeho vydán´ım vlastn´ı testován´ı, tak tato ˇcást nebyla zvláˇstˇe testována. Nad celou komponentou pak probˇehlo systémové testován´ı, jenˇz mˇelo za úkol ovˇeˇrit jej´ı funkˇcnost. To bylo provedeno autorem. T´ımto testován´ım komponenta proˇsla.

(33)

5 Aplikaˇ cn´ı server

Aplikaˇcn´ı server je stˇeˇzejn´ı komponentou celé platformy. Tato skuteˇcnost vycház´ı z kapitoly 3.3, jej´ımˇz závˇerem je pouˇzit´ı aplikaˇcn´ıho serveru jako prostˇredn´ıka mezi ostatn´ımi komponentami a úloˇziˇstˇem informac´ı ve formˇe databáze. S ohledem na zamˇeˇren´ı této práce na webové technologie se vývoj této komponenty ub´ırá smˇerem webových sluˇzeb a s t´ım spojených princip˚u a postup˚u.

5.1 Princip webov´ ych sluˇ zeb

Webovou sluˇzbu je moˇzné definovat jako webové API, které umoˇzˇnuje komunikaci systém˚u. V tomto momentu je d˚uleˇzitá právˇe myˇslenka o komunikaci systém˚u, protoˇze webové sluˇzby bˇeˇznˇe nemaj´ı svoje GUI. M´ısto nˇej ˇsiroce pouˇz´ıvaj´ı text jako formát pro výmˇenu dat. Komunikace pak prob´ıhá bez ohledu na to, v jakém jazyce jsou systémy vytvoˇreny. Z toho je vyplývaj´ıc´ı také platformová nezávislost.

Webové sluˇzby jako technologie jsou zastˇreˇsovány konsorciem W3C, které také defi- novalo jejich standard. Tento standart, dostupný z [13], by bylo moˇzné volnˇe pˇreloˇzit následovnˇe.

”Webová sluˇzba je softwarový systém podporuj´ıc´ı spolupráci mezi dvˇema stroji prostˇrednictv´ım poˇc´ıtaˇcové s´ıtˇe. Rozhran´ı webové sluˇzby je popsáno pomoc´ı strojovˇe zpracovatelného formátu. Ostatn´ı systémy komunikuj´ı s webovou sluˇzbou v souladu s pˇredepsaným WSDL rozhran´ım s pouˇzit´ım SOAP zpráv typicky pomoc´ı protokolu HTTP s XML serializac´ı, která je v souladu s dalˇs´ımi webovými standardy.“ [13]

Webové sluˇzby lze rozliˇsit na dvˇe základn´ı kategorie. Prvn´ı z nich jsou sluˇzby splˇnuj´ıc´ı podm´ınku stylu REST. Tyto sluˇzby vyuˇz´ıvaj´ı pro zpracován´ı dat sadu jednotných operac´ı, které jsou pro vˇsechny sluˇzby stejné. Druhou hlavn´ı tˇr´ıdou jsou potom libovolné sluˇzby (arbitrary web services). Tyto sluˇzby maj´ı na rozd´ıl od REST sluˇzeb moˇznost definice libovolné mnoˇziny operac´ı. Tato mnoˇzina je popsána pomoc´ı WSDL (Web Services Description Language). [13]

5.2 Pˇ rehled webov´ ych sluˇ zeb

5.2.1 SOAP

SOAP byl vytvoˇren jako odlehˇcený protokol pro výmˇenu strukturovaných informac´ı v decentralizovaném a distribuovaném prostˇred´ı. Je následovn´ıkem protokolu XML- RPC, který taktéˇz slouˇzil pro výmˇenu strukturovaných informac´ı. SOAP definuje