• No results found

3.3.1 Komponenty

Na z´akladˇe poˇzadavk˚u uveden´ych v kapitole 3.1 jsou definov´any z´akladn´ı kom-ponenty platformy. Jak vypl´yv´a z tˇret´ıho poˇzadavku, vˇsechny komponenty jsou navrˇzeny s ohledem na distribuovatelnost. T´ım je myˇsleno, aby kaˇzd´a z komponent byla pˇripraven´a na ˇsk´alovatelnost, na zv´yˇsen´ı jej´ıho v´ykonu, kapacity, ˇci prost´eho fyzick´eho oddˇelen´ı od zbytku platformy v pˇr´ıpadˇe potˇreby.

Prvn´ı takovou komponentou je Poskytovatel identit (IdP). Jej´ım ´ukolem je spr´ava identity jednotliv´ych uˇzivatel˚u a k n´ı pˇr´ısluˇsej´ıc´ı pˇr´ıstupov´e ´udaje. Dalˇs´ı nem´enˇe v´yznamnou funkc´ı je prov´adˇen´ı ovˇeˇrov´an´ı uˇzivatel˚u, kteˇr´ı se pokouˇsej´ı k plat-formˇe pˇristoupit a udˇelit jim patˇriˇcn´a opr´avnˇen´ı. A v okamˇziku pˇr´ıchoz´ıho poˇzadavku vˇzdy ovˇeˇrit, ˇze dan´y poˇzadavek a jeho p˚uvodce, uˇzivatel, sm´ı dan´y poˇzadavek prov´est.

Dalˇs´ı komponentou, z poˇzadavk˚u vypl´yvaj´ıc´ı, je Editor. Prostˇrednictv´ım kom-ponenty editoru z´ısk´a uˇzivatel pˇr´ıstup k uloˇzen´ym dat˚um, a to at’ uˇz v textov´e ˇci grafick´e podobˇe. Textovou podobou je myˇslena moˇznost n´ahledu a ´uprav pomoc´ı formul´aˇr˚u ˇci jin´ych k tomu potˇrebn´ych prostˇredk˚u tak, aby mˇel uˇzivatel moˇznost s daty pracovat. Grafickou podobou je myˇslena moˇznost vizualizace vybran´ych dat.

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

Spolupr´aci s extern´ımi programy, prozat´ım ve formˇe pˇreb´ır´an´ı dat z extern´ıho syst´emu, ˇreˇs´ı komponenta Import dat. Tato funkcionalita je dostupn´a z toho d˚uvodu, aby bylo moˇzn´e z extern´ıho syst´emu 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´e konkr´etn´ı programy. Praktick´a implementace je zamˇeˇrena na syst´em RIS.

Posledn´ı komponentou vypl´yvaj´ıc´ı z poˇzadavk˚u jsou V´ypoˇcty ´uloh. Vzhledem k faktu, ˇze existuje v´ıce typ˚u v´ypoˇcetn´ıch ´uloh, kter´e lze nad dan´ym schematem s´ıtˇe prov´adˇet, a s pˇrihl´ednut´ım k v´ykonov´ym moˇznostem r˚uzn´ych d´ale popsan´ych variant, je zapotˇreb´ı kl´ast u t´eto komponenty d˚uraz na modul´arnost, ˇsk´alovatelnost a vhodn´e techniky jej´ıho zpracov´an´ı.

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´e sd´ılen´ı napˇr´ıˇc zm´ınˇen´ymi komponentami. Toho lze dos´ahnout r˚uznˇe.

Prvn´ı variantou je, ˇze kaˇzd´a komponenta m´a vlastn´ı ´uloˇziˇstˇe dat, kter´e spravuje.

Tento pˇr´ıstup m´a relativn´ı v´yhodu v tom, ˇze nepˇrid´av´a do platformy dalˇs´ı kompo-nenty. Nicm´enˇe vˇetˇs´ı nev´yhodou se jev´ı jejich vz´ajemn´e prov´az´an´ı a n´asledn´a spr´ava.

Druh´a varianta tento probl´em ˇreˇs´ı za pomoci centr´aln´ıho ´uloˇziˇstˇe dat pro veˇsker´e komponenty. To je realizov´ano prostˇrednictv´ım datab´aze. Tento pˇr´ıpad je zachycen na obr´azku 3.1.

Obr´azek 3.1: Model platformy s centr´aln´ım ´uloˇ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´avislost na konkr´etn´ı pouˇzit´e datab´azi. V pˇr´ıpadˇe jej´ı zmˇeny ˇci v´ymˇeny za jinou by bylo potˇreba zasahovat do jednotliv´ych komponent. Pˇrestoˇze dnes nen´ı prak-ticky probl´em vytv´aˇret konkr´etn´ı komponenty s dostateˇcnou abstrakc´ı a pot´e jen konfigurac´ı nastavit konkr´etn´ı datab´azi, minim´alnˇe v tomto lze spatˇrovat onu nutnou modifikaci. Jej´ı v´yhodou se jev´ı rychlost zpracov´an´ı poˇzadavk˚u, protoˇze poˇzadavky zpracov´av´a pˇr´ımo datab´azov´y stroj.

Tˇret´ı variantou je pouˇzit´ı aplikaˇcn´ıho serveru (AS). Tento pˇr´ıpad je zn´azornˇen na obr´azku 3.2. Zde je patrn´e, ˇze prostˇredn´ıkem pro v´ymˇenu dat mezi komponen-tami (aplikacemi) a datab´az´ı je aplikaˇcn´ı server. Ten m˚uˇze podporovat r˚uzn´e zp˚usoby zpracov´an´ı poˇzadavk˚u a odpovˇed´ı a tak´e jejich r˚uzn´e form´aty. O t´eto problematice bl´ıˇze pojedn´av´a kapitola 5. V kontextu pˇredchoz´ıho odstavce je nutn´e zm´ınit, ˇze tato varianta m˚uˇze b´yt v urˇcit´ych situac´ıch v´ykonovˇe horˇs´ı, protoˇze m´ısto pˇr´ım´eho pˇr´ıstupu komponenty (aplikace) do datab´aze se ona komponenta obrac´ı de facto na prostˇredn´ıka, kter´y ji poˇzadovanou akci zprostˇredkuje. V dneˇsn´ı dobˇe existuj´ı techniky, napˇr. vhodn´e cachov´an´ı dat, s nimiˇz lze tyto probl´emy minimalizovat.

Na druhou stranu zde existuje minim´alnˇe jedna nepˇrehl´ednuteln´a v´yhoda. Tou je moˇznost specifikace dan´eho rozhran´ı nez´avisle na pouˇzit´e datab´azi a odst´ınˇen´ı konkr´etn´ı komponenty od nutnosti pˇresnˇe implementovat danou datab´azi. V praxi se jedn´a o to, ˇze aplikaˇcn´ı server poskytuje rozhran´ı ve formˇe definovan´ych struk-tur vol´an´ı ˇci pˇr´ıstupu k dat˚um. Tato vol´an´ı pak prov´ad´ı komponenta, kter´a nemus´ı ˇreˇsit, jak se data internˇe ukl´adaj´ı. Pro ni je pouze d˚uleˇzit´e, aby dok´azala praco-vat s dan´ym rozhran´ım, kter´e ji zpˇr´ıstupˇnuje aplikaˇcn´ı server. To pˇrin´aˇs´ı i druhou v´yhodu. Je pˇredem jasn´e, ˇc´ım aplikaˇcn´ı server disponuje a co naopak nepodporuje.

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

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

Na z´akladˇe pˇredchoz´ıho srovn´an´ı modelu bez aplikaˇcn´ıho serveru a s jeho pouˇzit´ım bylo zvoleno ˇreˇsen´ı, kter´e jej vyuˇz´ıv´a. Krom v´yˇse uveden´ych v´yhod 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´e sluˇzby.

3.3.3 Realizovatelnost komponent

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

Prvn´ı zm´ınˇenou komponentou je Poskytovatel identit. Z obr´azku 3.2 je pa-trn´e, ˇze ten pˇr´ımo s aplikaˇcn´ım serverem nekomunikuje. Pˇresto je zde jeden jedin´y okamˇzik, kdy doch´az´ı k nepˇr´ım´e 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´ance autorizaˇcn´ı. Tohoto ovˇeˇren´ı se vˇsak m˚uˇze zhostit aplikaˇcn´ı server s´am, jelikoˇz s´am m´a pˇr´ıstup k datab´azi uchov´avaj´ıc´ı autorizaˇcn´ı z´aznamy. Autorizaˇcn´ı z´aznam mus´ı vˇzdy vytvoˇrit poskytovatel identit. N´asledn´e ovˇeˇren´ı spoˇc´ıv´a pouze v kontrole jeho existence, coˇz je moˇzn´e prov´adˇet aplikaˇcn´ım serverem. Je moˇzn´e konstatovat, ˇze tato komponenta je realizovateln´a. Lze ji tak´e 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´e aplikace, je bez jak´ehokoli omezen´ı, ba naopak navazuje v duchu webu a jeho sluˇzeb na pˇredeˇsl´e. Je moˇzn´e jej realizovat bud’ jako

klasickou webovou aplikaci nebo t´eˇ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´y k´od aplikace sam´e je interpretov´an na klientovi v jeho prohl´ıˇzeˇci. Co se v´yˇse uveden´e funkcionality t´yk´a, toto ˇreˇsen´ı dok´aˇze pokr´yt veˇsker´e poˇzadavky. Tedy jak moˇznost pr´ace s daty ve formˇe jejich ´uprav prostˇrednictv´ım formul´aˇr˚u, tak i vizualizaci schematu s´ıt´ı.

Komponentu Import dat je tˇreba hodnotit ze dvou pohled˚u. Jednak je to imple-mentace, kter´a realizuje vlastn´ı proveden´ı importu dat nez´avisle na GUI. Tato ˇc´ast se jev´ı jako nekonfliktn´ı v˚uˇci aplikaˇcn´ımu serveru a poskytovateli identit, protoˇze pouze vyuˇz´ıv´a jimi poskytovan´e sluˇzby. Druh´y pohled je pak samotn´e GUI. V poˇzadavc´ıch kapitoly 3.1 se pro tuto komponentu uv´ad´ı, ˇze nen´ı potˇreba se zab´yvat GUI, n´ybrˇz ˇze staˇc´ı pouze UI ve formˇe termin´alov´eho ovl´ad´an´ı spouˇstˇen´e aplikace. I tento pohled je nekonfliktn´ı. Z toho tedy vypl´yv´a, ˇze komponenta import m˚uˇze b´yt vytvoˇrena jako termin´alov´a aplikace ovladateln´a pˇr´ıkazy termin´alu. To je vlastnˇe pˇredstupnˇem pro desktopovou grafickou nadstavbu. Nyn´ı se nab´ız´ı ot´azka, proˇc by to nemohla b´yt webov´a aplikace. Samozˇrejmˇe ˇze by j´ı mohla b´yt. ´Ulohou t´eto komponenty je importovat i rozs´ahl´a data. A to je v r´amci webov´e aplikace pˇrinejmenˇs´ım znaˇcnˇe diskutabiln´ı. Takov´a aplikace by totiˇz potˇrebovala prakticky neomezen´y ˇcas bˇehu j´ı sam´e. T´ım je m´ıˇreno na interpretovan´e jazyky na webov´em serveru s nastavenou maxim´aln´ı dobou trv´an´ı dan´eho skriptu. Pr´avˇe ta by mohla zp˚usobit jeho pˇredˇcasn´e ukonˇcen´ı dˇr´ıve neˇz se dan´e operace dokonˇc´ı. Je tu moˇznost toto nastaven´ı upravit, nicm´enˇe je ot´azkou, zda-li by se i po t´eto ´upravˇe jednalo o vhodnou volbu tˇreba pr´avˇe z hlediska v´ykonu.

Posledn´ı komponentou je komponenta V´ypoˇct˚u ´uloh. Jej´ım ´ukolem je, jak jiˇz n´azev napov´ıd´a, prov´adˇen´ı v´ypoˇct˚u matematick´ych ´uloh. Je zˇrejm´e, ˇze v prvn´ı ˇradˇe hraje roli efektivita v´ypoˇctu spolu s dostupn´ym v´ypoˇcetn´ım v´ykonem. Poˇzadavky typu paralelizovatelnost ˇci v´ıce vl´aknov´e zpracov´an´ı jsou na pˇredn´ıch pˇr´ıˇck´ach. Pr´avˇe z tohoto d˚uvodu je prakticky vylouˇcen´e, aby v´ypoˇcty prov´adˇel webov´y prohl´ıˇzeˇc uˇzivatele. Pˇrestoˇze jiˇz dnes nˇekter´e webov´e prohl´ıˇzeˇce pracuj´ı tak, ˇze kaˇzd´y otevˇren´y panel bˇeˇz´ı ve sv´em vlastn´ım procesu, st´ale se ned´a mluvit o dostateˇcnˇe dostupn´em v´ykonu. Tˇeˇzko si pˇredstavit uˇzivatele, kter´y si ve sv´em webov´em prohl´ıˇzeˇci, byt’

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

Tato kapitola se tak vlastnˇe stala zdrojem odpovˇed´ı ot´azky poloˇzen´e v ´uvodu t´eto diplomov´e pr´ace. Odpov´ıd´a na stˇeˇzejn´ı ot´azky, kdy, kde a zda m´a smysl pouˇz´ıt webov´e technologie. Jejich pouˇzit´ı je pops´ano v kapitol´ach jednotliv´ych komponent.

Related documents