API Connector

API Connector je desktopov´a aplikace vytvoˇren´a v jazyce Java. Implementuje spo-jen´ı s aplikaˇcn´ım serverem a odstiˇnuje d´ale vyv´ıjen´e aplikace od potˇreby vlastn´ı implementace API poskytovan´em aplikaˇcn´ım serverem. Jde tak v podstatˇe o wrap-per, nebo-li obal, k API aplikaˇcn´ıho serveru na lok´aln´ı ´urovni. Z kapitoly 3.1 je v tuto chv´ıli zˇrejm´e, ˇze minim´alnˇe komponenta importu a komponenta v´ypoˇct˚u mo-hou b´yt realizov´any napˇr. v jazyce Java. Budou pˇr´ımo komunikovat s aplikaˇcn´ım serverem prostˇrednictv´ım j´ım poskytovan´eho API. Proto je v tento moment vhodn´e takov´yto wrapper pˇripravit a n´aslednˇe pˇri jejich tvorb´ach pouze vyuˇz´ıt. Pˇri znalosti komponent, kter´e tento konektor vyuˇzij´ı, jsou pro jejich potˇreby implementov´any pouze takov´e zdroje (v bal´ıˇcku resources.* ), kter´e se prakticky vyuˇzij´ı. N´aslednˇe je moˇzn´e v budoucnu doimplementovat zb´yvaj´ıc´ı zdroje podle potˇreby. Implemento-van´e zdroje byly jednotkovˇe otestov´any. Tˇemito testy vˇsechny zdroje proˇsly.

6 Editor

Uˇ´celem t´eto komponenty je poskytnout bˇeˇzn´emu uˇzivateli grafick´y n´astroj pro pr´aci se schematem s´ıtˇe, prvky schematu a tak´e s t´ım souvisej´ıc´ı prov´adˇen´ı dostupn´ych typ˚u v´ypoˇcetn´ıch ´uloh. Doposud zm´ınˇen´e a popsan´e komponenty tuto funkcionalitu totiˇz nenab´ızej´ı a z pohledu editoru jsou podp˚urn´e, avˇsak nezbytn´e, pro jeho ˇcinnost.

Jedn´ım ze z´avˇer˚u kapitoly 3.3 je skuteˇcnost, ˇze v´ypoˇcty dostupn´ych v´ypoˇcetn´ıch ´uloh jsou prov´adˇeny na samostatn´em uzlu k tomu urˇcen´em. Z toho vypl´yv´a, ˇze editor m´a podporovat spr´avu takov´ychto v´ypoˇcetn´ıch ´uloh, nikoli je aktivnˇe prov´adˇet.

K editoru m´a b´yt umoˇznˇen pˇr´ıstup pouze autorizovan´emu uˇzivateli. Autorizaci a j´ı pˇredch´azej´ıc´ı autentizaci ˇreˇs´ı poskytoval identit (viz kapitola 4).

6.1 N´ avrh aplikace

Z´akladn´ım krit´eriem webov´e aplikace je, kromˇe jej´ıho provozu v r´amci webu, zp˚usob jej´ıho spuˇstˇen´ı a n´asledn´eho zpracov´an´ı poˇzadavk˚u. To m˚uˇze prob´ıhat odesl´an´ım poˇzadavku na server a opˇetovn´ym staˇzen´ım novˇe vygenerovan´e str´anky. Naproti tomu je moˇzn´e str´anku naˇc´ıst pouze jednou a poˇzadavky pak pˇred´avat na server oddˇelenˇe a pouze zpracov´avat pˇrijat´e odpovˇedi. To vˇse tedy bez znovu naˇc´ıt´an´ı novˇe vygenerovan´e str´anky. Tuto druhou techniku je moˇzno nal´ezt pod zkratkou SPA, nebo-li single page application ˇci ˇcesky jednostr´ankov´a aplikace. Je zˇrejm´e, ˇze kaˇzd´a z tˇechto technik m´a sv´e v´yhody a nev´yhody. Jedn´ım z nich je napˇr´ıklad pouˇzit´ı JavaScriptu, jako programovac´ıho jazyka na stranˇe klienta (webov´eho prohl´ıˇzeˇce).

Zat´ımco prvn´ım zp˚usobem zpracovan´a aplikace jej ke sv´e funkci v z´asadˇe nepotˇrebuje, ˇc´ımˇz se samozˇrejmˇe neˇr´ık´a, ˇze by jej nemohla vyuˇz´ıt, tak aplikace vytvoˇren´a druh´ym zp˚usobem je na nˇem zcela z´avisl´a. Pr´avˇe z´avislost na Javacriptu m˚uˇze b´yt slabi-nou dan´e aplikace, jelikoˇz jeho deaktivaci m˚uˇze ve sv´em prohl´ıˇzeˇci prov´est samotn´y uˇzivatel. V tom pˇr´ıpadˇe by druh´a aplikace pˇrestala fungovat. Je korektn´ı zm´ınit, ˇze pr´avˇe zm´ınˇen´y druh´y zp˚usob vytv´aˇren´ı webov´ych aplikac´ı je trendem posledn´ı doby a zcela jistˇe m´a sv´e opodstatnˇen´e zastoupen´ı.

Pˇr´ıstup SPA je vhodn´ym kandid´atem pro komponentu editoru. To pˇredevˇs´ım z d˚uvodu potˇreby dynamick´eho vykreslov´an´ı schemat, kter´e by prvn´ım uveden´ym pˇr´ıstupem bylo znaˇcnˇe komplikovan´e. Dalˇs´ı v´yhodou pak je pˇredpokl´adan´a ´uspora pˇrenesen´ych dat. Vzhledem k pouˇzit´ı protokolu HTTP2 a techniky SPA, je pak tento pˇredpoklad opr´avnˇen´y. Pˇri prvn´ım naˇcten´ı str´anky se naˇctou vˇsechny potˇrebn´e soubory se zdrojov´ymi k´ody a grafick´ymi podklady, kter´e jsou potˇrebn´e pro bˇeh samotn´e aplikace, a pot´e jiˇz prob´ıh´a pouze komunikace s aplikaˇcn´ım serverem za

´

uˇcelem v´ymˇeny konkr´etn´ıch dat konkr´etn´ıch zdroj˚u. Tedy takov´ych zdroj˚u, kter´e aplikace potˇrebuje pro sv˚uj chod.

6.1.1 Pˇ r´ıpady uˇ zit´ı

Obr´azek 6.1: Diagram pˇr´ıpad˚u uˇzit´ı

Obr´azek 6.1 zachycuje diagram pˇr´ıpad˚u uˇzit´ı t´eto komponenty. Je z nˇej pa-trn´ych nˇekolik skuteˇcnost´ı. Pˇrednˇe editor obsahuje ˇctyˇri tematick´e okruhy – schema, mapu, v´ypoˇcty a uˇzivatele. V r´amci kaˇzd´eho tohoto okruhu je definov´ana jeho urˇcit´a funkcionalita.

Prvn´ım takov´ym okruhem je schema. Schema je zastˇreˇsuj´ıc´ı prvek elektrick´e resp. modelovan´e s´ıtˇe. S n´ım jsou totiˇz sv´az´any vˇsechny prvky, kter´e se v dan´em schematu vyskytuj´ı. V r´amci platformy a t´ım i pˇr´ısluˇsn´eho datov´eho ´uloˇziˇstˇe nem˚uˇze existovat prvek s´ıtˇe, kter´y by nebyl pˇriˇrazen do nˇejak´eho schematu. Nad kaˇzd´ym prvkem by d´ale mˇela b´yt funkcionalita pro jeho vytvoˇren´ı, ´upravy a odebr´an´ı. Se schematem jeˇstˇe ´uzce souvisej´ı opr´avnˇen´ı. Ke schematu je totiˇz umoˇznˇen pˇr´ıstup tˇem uˇzivatel˚um, kteˇr´ı jsou u dan´eho schematu uvedeni jako povolen´ı a maj´ı pˇr´ısluˇsn´e opr´avnˇen´ı. T´ım je myˇsleno opr´avnˇen´ı pro ˇcten´ı, z´apis nebo spouˇstˇen´ı ´uloh. To vˇse je ˇcasovˇe omezen´e v r´amci opr´avnˇen´ı.

Dalˇs´ım okruhem jsou mapy vyuˇz´ıvaj´ıc´ı n´astroje, kter´e zahrnuj´ı operace pˇribl´ıˇzen´ı

a odd´alen´ı mapy, obnoven´ı jiˇz vykreslen´e mapy a posun mapy podle uˇzivatelsk´ych preferenc´ı. Tyto n´astroje by mˇely slouˇzit pro z´akladn´ı vizualizaci dan´e mapy, resp.

graficky vyj´adˇren´eho schematu. Zde se d´ale nab´ız´ı rozˇs´ıˇren´ı o dalˇs´ı vybran´e n´astroje ˇreˇs´ıc´ı napˇr. online editaci, pokroˇcilejˇs´ı zobrazen´ı rozs´ahl´ych map ˇci geografick´e mapy.

S nimi je v souˇcasn´em n´avrhu a uspoˇr´ad´an´ı datov´ych model˚u jiˇz uvaˇzov´ano.

Tˇret´ım okruhem jsou v´ypoˇcty. Jak jiˇz bylo uvedeno v ´uvodu t´eto kapitoly, editor ze sv´e podstaty v´ypoˇcty nevykon´av´a. M´ısto toho ˇreˇs´ı spr´avu ´uloh, kter´e se n´aslednˇe pˇredaj´ı v´ypoˇcetn´ım uzl˚um k proveden´ı. Pro tyto ´uˇcely tedy editor mus´ı podporovat pr´aci s ´ulohami, zn´at implementovan´e v´ypoˇcetn´ı ´ulohy a tak´e m´ıt k dispozici pˇrehled v´ypoˇcetn´ıch uzl˚u.

Posledn´ım okruhem jsou pak uˇzivatel´e. V kontextu editoru je t´ım myˇsleno pouh´e zobrazen´ı jejich seznamu, protoˇze dalˇs´ı funkce na toto nejsou poˇzadov´any.

Zde je vhodn´e pˇripomenout skuteˇcnost, ˇze vlastn´ı spr´avu uˇzivatelsk´ych identit, a t´ım p´adem i dostupn´ych uˇzivatel˚u, prov´ad´ı komponenta poskytovatele identit platformy (viz kapitola 4).

6.2 Implementace

Pro tvorbu byl zvolen jazyk JavaScript a to z d˚uvodu, ˇze se v koneˇcn´e f´azi jedn´a o jedin´y jazyk pro vytv´aˇren´ı webov´ych SPA. Stejnˇe jako u pˇredeˇsl´ych komponent, kde se vyuˇz´ıval konkr´etn´ı framework, tak i zde byl takov´y pouˇzit, konkr´etnˇe Angu-larJS ve verzi 1.5 (viz [26]). Ten byl zvolen ˇcistˇe na z´akladˇe faktu, ˇze v dobˇe volby se jednalo o posledn´ı stabiln´ı a produkˇcn´ı verzi. P˚uvodnˇe bylo zvaˇzov´ano pouˇzit´ı frameworku Angular 2, nicm´enˇe kv˚uli prob´ıhaj´ıc´ımu v´yvoji, a tud´ıˇz neexistence sta-biln´ı a produkˇcn´ı verze, od nˇej bylo upuˇstˇeno. Nicm´enˇe pro budouc´ı aktualizaci t´eto komponenty je moˇzn´e jej uvaˇzovat.

AngularJS pomoc´ı architektury MVC umoˇzˇnuje oddˇelen´ı aplikaˇcn´ı logiky od da-tov´eho modelu a uˇzivatelsk´eho rozhran´ı. Uˇz tento smˇer pˇredznamen´av´a zp˚usob pr´ace v takov´emto projektu. Kromˇe architektury MVC obsahuje i dalˇs´ı praktick´e techniky zn´am´e z jin´ych framework˚u a jazyk˚u. Mezi z´asadn´ı patˇr´ı DI (Dependency Injection ˇci ˇcesky vkl´ad´an´ı z´avislost´ı) ˇci Two Way Data-Binding (ˇcesky obousmˇern´e mapov´an´ı dat). Pr´avˇe druh´a technika je na tomto frameworku velmi praktick´a. Pomoc´ı n´ı lze deklarativnˇe prov´azat GUI s modelem. Nen´ı tˇreba specifikovat zp˚usob, jak´ym se m´a GUI s modelem synchronizovat. O to se totiˇz automaticky postar´a Angular.

6.2.1 Autentizace a autorizace

Za pouˇzit´ı Angularu byl vytvoˇren editor, kter´y implementuje funkce popsan´e v kapi-tole 6.1. Vzhledem ke skuteˇcnosti, ˇze k dat˚um je povolen pˇr´ıstup pouze autorizo-van´ym uˇzivatel˚um, tak je zapotˇreb´ı se j´ı bl´ıˇze zab´yvat. Autentizaci a autorizaci ˇreˇs´ı komponenta poskytovatele identit (viz kapitola 4). Je proto nemysliteln´e, aby se cokoli z jeho problematiky odehr´avalo na stranˇe editoru. Principi´alnˇe jde totiˇz o situaci, kdy uˇzivatel m´a zad´avat sv´e pˇr´ıstupov´e ´udaje hlavn´ıho pˇr´ıstupov´eho ´uˇctu pouze v˚uˇci poskytovateli identit a nikoli v˚uˇci jin´ym aplikac´ım. T´ım je totiˇz zajiˇstˇena

nezanedbateln´a ´uroveˇn bezpeˇcnosti, protoˇze nem˚uˇze doj´ıt k bezprostˇredn´ımu zneuˇzit´ı

´

udaj˚u ze strany jin´e aplikace. ˇReˇsen´ım je pˇresmˇerov´an´ı uˇzivatele na autentizaˇcn´ı str´anku poskytovatele identit. Ten ovˇeˇr´ı pˇr´ıstupov´e ´udaje. V kladn´em pˇr´ıpadˇe zo-braz´ı uˇzivateli autorizaˇcn´ı formul´aˇr. Jeho obsahem je struˇcn´e informov´an´ı uˇzivatele o tom, ˇze aplikace, ze kter´e vzeˇsel poˇzadavek pˇr´ıstupu, se pokouˇs´ı tento pˇr´ıstup k chr´anˇen´ym zdroj˚um z´ıskat. Pokud jej uˇzivatel odsouhlas´ı, je pˇresmˇerov´an zpˇet do editoru, kde probˇehne dokonˇcen´ı procesu pˇrihl´aˇsen´ı. N´aslednˇe m˚uˇze uˇzivatel aplikaci pouˇz´ıvat. Tento postup schematicky zn´azorˇnuje obr´azek 6.2.

Obr´azek 6.2: Pˇrihl´aˇsen´ı do editoru pomoc´ı IdP

Z hlediska bezpeˇcnosti je d˚uleˇzit´e k obr´azku 6.2 poznamenat, ˇze takto uveden´y postup by byl s´am o sobˇe zraniteln´y. Zranitelnost v tomto pˇr´ıpadˇe spoˇc´ıv´a v CSRF (viz [22]). V okamˇziku pˇr´ıchoz´ıho autorizaˇcn´ıho k´odu do editoru od poskytovatele identit by totiˇz nebylo zajiˇstˇeno, ˇze ten nen´ı nastrˇcen pˇr´ıpadn´ym ´utoˇcn´ıkem, kter´y se pokouˇs´ı z´ıskat uˇzivatelovu identitu. Proto se jako opatˇren´ı pouˇzije dalˇs´ı parametr, zde konkr´etnˇe state, v URL, kter´y obsahuje pouze n´ahodnˇe generovan´y ˇretˇezec. Pˇri pˇr´ıjmu odpovˇedi od poskytovatele identit se pak porovn´av´a takto poslan´y a lok´alnˇe uloˇzen´y ˇretˇezec s dorazivˇs´ım. Pokud ten chyb´ıˇci neodpov´ıd´a, jedn´a se pravdˇepodobnˇe o ´utok. V tom pˇr´ıpadˇe se pˇrihl´aˇsen´ı nedokonˇc´ı. Dokonˇcen´ım pˇrihl´aˇsen´ı se rozum´ı v´ymˇena dorazivˇs´ıho autorizaˇcn´ıho k´odu za k´od pˇr´ıstupov´y, kter´a se n´aslednˇe odehraje mezi klientem a poskytovatelem identit.

Aby se nemusel pˇri kaˇzd´em pos´ılan´em poˇzadavku na aplikaˇcn´ı server do hlaviˇcek programovˇe doplˇnovat pˇr´ıstupov´y k´od, je zde vyuˇzita technika tzv. Interceptor.

Jedn´a se de facto o sluˇzbu, kter´a se provede pˇred odesl´an´ım poˇzadavku ˇci pˇri pˇrijet´ı odpovˇedi. Samozˇrejm´a je i moˇznost jejich pouˇzit´ı s chybovou odpovˇed´ı. Zde v editoru

je implementov´ana prvn´ı funkcionalita, tedy pˇred kaˇzd´ym vol´an´ım poˇzadavku na aplikaˇcn´ı server se do tohoto poˇzadavku vloˇz´ı autorizaˇcn´ı hlaviˇcka s pˇr´ıstupov´ym k´odem. Pro pˇr´ıpad pˇr´ıchodu jak´ekoli odpovˇedi od aplikaˇcn´ıho serveru, kter´a by obsahovala n´avratov´y k´od 401 nebo 403, coˇz by znaˇcilo neplatn´y pˇr´ıstupov´y k´od, se zde implementaˇcnˇe oˇsetˇruje i dorazivˇs´ı odpovˇed’.

Pro ´uˇcely grafick´e vizualizace schematu elektrick´e s´ıtˇe je pouˇzita extern´ı knihovna vis.js, kter´a se zamˇeˇruje na tvorbu graf˚u, s´ıt´ı, ˇcasov´y ˇrad atp. Jej´ı ovl´ad´an´ı ˇreˇs´ı pˇr´ısluˇsn´a komponenta editoru, kter´a vykresluje schematickou mapu zvolen´e s´ıtˇe, resp. schematu. D´ale byly pouˇzity vybran´e konstrukty z nov´eho ES2015, coˇz je nov´a verze ECMAScriptu. Mezi tyto konstrukty patˇr´ı napˇr. tˇr´ıdy v obvykl´em v´yznamu, blokovˇe viditeln´e promˇenn´e, moduly a tzv. promisses coˇz jsou de facto tˇr´ıdy, jejichˇz hodnota bude zn´am´a v budoucnu. Ty se pouˇz´ıvaj´ı pˇri asynchronn´ım programov´an´ı a jejich praktick´e uplatnˇen´ı je pˇri komunikaci s extern´ımi zdroji, v pˇr´ıpadˇe editoru komunikace s aplikaˇcn´ım serverem.

Cel´y k´od komponenty je vytvoˇren v prostˇren´ı node.js za pouˇzit´ı JavaScrip-tov´eho kompil´atoru Babel, spr´avce bal´ık˚u Bower a bal´ıˇckovac´ıho syst´emu Web-pack. Ten, jako fin´aln´ı ´upravu, prov´ad´ı slouˇcen´ı vˇsech soubor˚u s programov´ymi ˇc´astmi do jedin´eho, coˇz ve v´ysledku ˇsetˇr´ı poˇcet HTTP poˇzadavk˚u.

V pˇr´ıloze E je pro uk´azku zobrazena schematick´a mapa ˇc´asti schematu s´ıtˇe ˇZelkovice.

6.3 Testov´ an´ı

Testov´an´ı t´eto komponenty prob´ıhalo za pomoc´ı n´asleduj´ıc´ıch technik. Po vytvoˇren´ı dan´eho k´odu byl k´od testov´an program´atorem. Vzhledem k faktu, ˇze se zde vyuˇz´ıvaly extern´ı knihovny a moduly, kter´e pˇred sv´ym zveˇrejnˇen´ım proˇsly vlastn´ım testov´an´ım, tak tato ˇc´ast nebyla zvl´aˇstˇe testov´ana. Nad celou komponentou probˇehlo syst´emov´e testov´an´ı, jenˇz mˇelo za ´ukol ovˇeˇrit jej´ı funkˇcnost. To bylo provedeno autorem. T´ımto testov´an´ım komponenta proˇsla.

6.4 Provozn´ı prostˇ red´ı

Editor je naps´an v jazyce JavaScript za pouˇzit´ı HTML, CSS a dalˇs´ıch potˇrebn´ych technik. S t´ım souvis´ı i moˇznosti jeho provozov´an´ı. Jelikoˇz se jedn´a o klientskou aplikaci (SPA), kter´a se tedy bude spouˇstˇet na stranˇe uˇzivatele v jeho webov´em prohl´ıˇzeˇci, pak nen´ı potˇrebn´e na stranˇe serveru pouˇz´ıvat jak´ekoli skriptovac´ı jazyky.

Webov´y server tak m´a pouze za ´ukol distribuovat statick´y obsah. T´ım jsou myˇsleny pr´avˇe JavaScriptov´e k´ody, HTML, styly atp. Jako webov´y server byl v tomto pˇr´ıpadˇe zvolen Nginx. Nic ale nebr´an´ı pouˇzit´ı kter´ehokoli jin´eho. Ve spojen´ı s Nginx, a tak´e s d˚urazem na bezpeˇcnost, je nastaveno zabezpeˇcen´e spojen´ı HTTPS mezi t´ımto distribuˇcn´ım serverem a webov´ym prohl´ıˇzeˇcem uˇzivatele. Stejnˇe jako u aplikaˇcn´ıho serveru, tak i tento pouˇz´ıv´a certifik´at vydan´y certifikaˇcn´ı autoritou Let’s Encrypt a tak´e HTTP2 protokol.

7 Propojen´ı se syst´ emy tˇ ret´ıch stran

Jak jiˇz n´azev samotn´e kapitoly naznaˇcuje, je na m´ıstˇe v tento moment uvaˇzovat jeˇstˇe o moˇznosti propojen´ı platformy se syst´emy tˇret´ıch stran. Staˇc´ı vzpomenout na ´uvod kapitoly 2, ve kter´em je zm´ınˇena pˇr´ıtomnost syst´emu RIS u konzultanta.

Minim´alnˇe z tohoto ´uhlu pohledu by se tedy mohlo jednat o vhodnou komponentu platformy, protoˇze je pravdˇepodobn´e, ˇze potenci´aln´ı uˇzivatel t´eto platformy bude obdobn´y software jiˇz pouˇz´ıvat. Vzhledem k proklamovan´e otevˇrenosti platformy by tak mohl i tento uˇzivatel projevit z´ajem o propojen´ı syst´emu s platformou, pokud by jiˇz neexistovalo.

7.1 Principy propojen´ı syst´ em˚ u

Dva obecnˇe heterogenn´ı syst´emy nemus´ı b´yt v˚ubec snadn´e propojit. Zvl´aˇstˇe, pokud se jedn´a o komerˇcn´ı produkty, ke kter´ym nen´ı pˇr´ıstup ve formˇe zdrojov´ych k´od˚u ˇci pˇr´ıstup k datov´ym ´uloˇziˇst´ım. Tato situace m´a pak alespoˇn dvˇe strany. Jed-nou je syst´em, kter´y data poskytuje. Druhou je pak syst´em, kter´y data pˇrij´ım´a a ukl´ad´a. Minim´alnˇe na ´urovni praktick´ych moˇznost´ı, a zdaleka nepostihuj´ıc´ı vˇsechny moˇznosti, je n´asleduj´ıc´ı v´yˇcet. V nˇem je pod zkratkou DB myˇslena datab´aze a pod zkratkou API libovoln´e API napˇr. ve formˇe webov´ych sluˇzeb. Nˇekter´e z moˇznost´ı propojen´ı jsou:

• DB – DB,

• API – API,

• soubor – soubor,

• soubor – DB,

• soubor – API.

Datab´aze, pˇri vhodn´em hardwarov´em vybaven´ı a pˇri jej´ım vhodn´em n´avrhu a optimalizaci, m˚uˇze vynikat sv´ymi v´ykony na poli rychlosti zpracov´an´ı a orga-nizaci dat. Jej´ı nev´yhodou je softwarov´a z´avislost na konkr´etnˇe zvolen´ych datab´az´ıch a v pˇr´ıpadˇe jejich nehomogenity, myˇsleno neexistence totoˇzn´ych datab´azov´ych server˚u na obou stran´ach, i vz´ajemn´a nekompatibilita. To lze do jist´e m´ıry vyˇreˇsit modelem s pouˇzit´ım soubor˚u. Nicm´enˇe zde tak´e vyvst´av´a cel´a ˇrada ot´azek poˇc´ınaje zp˚usobem pˇrenosu, k´odov´an´ım, jeho velikost´ı a konˇce jejich spr´avou. Posledn´ı moˇznost´ı je

pouˇzit´ı API. To do jist´e m´ıry dok´aˇze eliminovat nedostatky pˇredchoz´ıch. Pˇri jeho spr´avn´em n´avrhu bude slouˇzit univerz´alnˇe pro v´ıce ´uˇcel˚u a t´ım lze i minimalizovat softwarov´e n´aklady. Nelze tvrdit, ˇze jak´akoli moˇznost je ˇspatn´a. Vˇzdy bude z´aleˇzet na konkr´etn´ı situaci a parametrech, kter´e do n´ı budou vstupovat. Jako pˇr´ıklad parametr˚u lze uv´est napˇr. spojen´ı po s´ıti a s t´ım souvisej´ıc´ı rychlost ˇci prodleva pˇrenosu, velikost pˇren´aˇsen´ych dat atp.