Design and implement user interface for robotics network of telesocpes with RTS2

(1)

ˇ

Cesk´

e vysok´

e ´

uˇ

cen´ı technick´

e

v Praze

Fakulta elektrotechnick´

a

Katedra poˇ

c´ıtaˇ

c˚

u

N´

avrh a implementace uˇzivatelsk´eho

rozhran´ı s´ıtˇe robotick´

ych dalekohled˚

u

ˇr´ızen´

ych syst´emem RTS2

Diplomov´

a pr´

ace

Autor: Bc. Radek Meˇciar

Studijn´ı obor: Otevˇren´

a informatika

Zamˇeˇren´ı: Poˇc´ıtaˇcov´e inˇzen´

yrstv´ı

(2)

(3)

Czech Technical University in Prague Faculty of Electrical Engineering

Department of Control Engineering

DIPLOMA THESIS ASSIGNMENT

Student: Mečiar Radek

Study programme: Open Informatics Specialisation: Computer Engineering

Title of Diploma Thesis: Design and implement user interface for robotics network of telesocpes with RTS2

Guidelines:

1. Get knowledge about RTS2

2. Design and implement modular user interface according these conditions (a) Distinguish access level for every telescope and user

(b) Allow real-time controll telescope

(c) Planning of observations in whole telescope network

(d) Implement data access interface considering data flow optimalization (e) Notifications for client (WebSocekt)

3. Implement missing functionalities in RTS2 4. Evaluate capability and usability of application

Bibliography/Sources:

[1] Petr Kubánek, "RTS2: The Remote Telescope System," Advances in Astronomy, vol. 2010, Article ID 902484, 9 pages, 2010. doi:10.1155/2010/902484

[2] Kubánek, Petr, et al. "RTS2: meta-queues scheduling and its realisation for FLWO 1.2 m telescope." SPIE Astronomical Telescopes+ Instrumentation. International Society for Optics and Photonics, 2012.

[3] Pérez-del-Pulgar, Carlos Jesús, et al. "GLORIA: The First Free Access e-Infrastructure of Robotic Telescopes for Citizen Science." Advances in Information Systems and Technologies. Springer Berlin Heidelberg, 2013. 293-304.

Diploma Thesis Supervisor: Ing. Stanislav Vítek, Ph.D. Valid until the summer semester 2017/2018

prof. Ing. Michael Šebek, DrSc. Head of Department

prof. Ing. Pavel Ripka, CSc. Dean

(4)

(5)

Prohl´

aˇ

sen´ı

Prohlaˇsuji, ˇze jsem pˇredloˇzenou práci vypracoval samostatnˇe a ˇze jsem uvedl veˇskeré pouˇzité informaˇcn´ı zdroje v souladu s Metodickým pokynem o dodrˇzován´ı etických princip˚u pˇri pˇr´ıpravˇe vysokoˇskolských závˇereˇcných prac´ı.

(6)

(7)

Podˇ

ekov´

an´ı

Zde bych rád podˇekoval svému vedouc´ımu práce Ing. Stanislavu V´ıtkovi, Ph.D pˇredevˇs´ım za zaj´ımavé téma a za pomoc s ˇreˇsen´ım, hlavnˇe pˇri hledán´ı informac´ı.

(8)

(9)

Abstrakt

Práce se zabývá návrhem a implementac´ı softwaru pro sjednocen´ı pˇr´ıstupu k ob-servatoˇr´ım vyuˇz´ıvaj´ıc´ıch systém RTS2. C´ılem práce je zpˇrehlednit a ulehˇcit ovládán´ı observatoˇr´ı z jednoho m´ısta, spoleˇcnˇe s náhradou konzolového pˇr´ıstupu ovládán´ı. Hlavn´ım výsledkem práce je software. Konkrétnˇe se jedná o webovou aplikaci, která se skládá z JavaScriptové klientské ˇcásti a serveru napsaného v jazyce Java. Práce dále shrnuje základn´ı informace o systému RTS2, které jsou potˇrebné k implemen-taci. Hlavn´ı analýza RTS2 systému se týká HTTP metod, které umoˇzˇnuj´ı vzájemnou komunikaci mezi servery. Výsledkem práce je serverové ˇreˇsen´ı, které je schopné ko-munikovat s v´ıce systémy RTS2. Vytvoˇrený server pouˇz´ıvá protokol HTTP, jako klient, tak jako server pro pˇr´ıstup. Pro serverovou ˇcást byl implementován Web-Socket server a zprovoznˇena ukázková funkce. Klientská ˇcást je schopna se pˇripojit a komunikovat s vytvoˇreným serverem. Je urˇcena k pˇrehlednému podán´ı informac´ı uˇzivateli. Vytvoˇrená aplikace umoˇzˇnuje správu uˇzivatel˚u a systém˚u RTS2, jejich c´ıl˚u pozorován´ı, zaˇr´ızen´ı a jednotlivých parametr˚u, front pro plánován´ı a umoˇzˇnuje pˇr´ıstup k napozorovaným dat˚um.

Key words

rts2, SPA, ovl´ad´an´ı, dalekohled, observatoˇr, teleskop, web, server, klient, remote telescope system, JavaScript, AngularJS, Bootstrap, Java, PostgreSQL

(10)

(11)

Abstract

The thesis deals with design and implementation of a software for a control uni-fication with observatories using the RTS2 system. The objective of the thesis is to facilitate and simplify the control of an observatory from one web application together with a console access control replacement. The main result of the thesis is the software. Specifically, the software is a web solution that consists of a JavaScript client and a Java server. The thesis also analyzes basic inforamtions about the RTS2 system in volume needed for the implementation. The analysis of the RTS2 system concerns HTTP methods that allow communication between servers. The created server uses HTTP as a client as well as an server and it is able to communicate with multiple RTS2 systems. Basic WebSocket protocol was implemented for the server part and also with a demonstartion of use. The client part is able to communicate with server part and provide informations for users. Created solution enables an administration of users, observatories, targets, devices and their properties, queues management for planing of observations and pictures access considering data flow optimalization.

Key words

rts2, SPA, control, telescope, observatory, web, server, client, remote telescope sys-tem, single page application, JavaScript, AngularJS, Bootstrap, Java, PostgreSQL

(12)

(13)

Obsah

1 Uvod´ 17

1.1 Popis poˇzadavk˚u pr´ace . . . 17

1.2 Motivace . . . 19

1.3 Zdroje pro pr´aci . . . 19

2 Anal´yza 21 2.1 Remote Telescope System 2 . . . 21

2.1.1 JSON API . . . 21

2.1.2 Pˇr´ıstup k napozorovan´ym dat˚um . . . 21

2.2 Anal´yza souˇcasn´ych projekt˚u . . . 22

2.3 V´ybˇer technick´eho pozad´ı . . . 23

2.3.1 Typ komunikace server - klient . . . 23

2.3.2 V´ybˇer konkr´etn´ıch technologi´ı . . . 24

2.3.3 Datab´aze . . . 25

2.3.4 Administrace projektu . . . 25

3 Popis zvoleného ˇreˇsen´ı 27 3.1 Klientská ˇcást RTS2 UI . . . 27

3.1.1 Hlavn´ı soubor klienta - index.html . . . 27

3.1.2 Hlavn´ı soubor JS - app.js . . . 28

3.1.3 Kontrolery . . . 30

3.1.4 Rozloˇzen´ı . . . 31

3.1.5 Servisy . . . 31

3.2 Serverov´a ˇc´ast RTS2 UI . . . 32

3.2.1 Konfigurace serveru . . . 33

3.2.2 Hlavn´ı logika aplikace . . . 33

3.2.3 HTTP rozhran´ı serverov´e ˇc´asti . . . 35

3.3 Datab´aze RTS2 UI . . . 39

4 Popis funkce 41 4.1 Spr´ava observatoˇr´ı . . . 41

4.2 Ovl´adan´ı zaˇr´ızen´ı . . . 43

4.3 Spr´ava c´ıl˚u pozorov´an´ı . . . 48

4.3.1 Seznam c´ıl˚u . . . 48

4.3.2 Editace a vytvoˇren´ı c´ıle . . . 49

4.4 Pl´anov´an´ı . . . 50

4.4.1 Pˇrid´an´ı c´ıle do fronty . . . 51

4.4.2 Zobrazen´ı fronty . . . 52

4.4.3 Zobrazen´ı pl´anu . . . 53

(14)

Obsah

4.5.1 Podle data pozorován´ı . . . 53 4.5.2 Podle c´ıle pozorován´ı . . . 54 4.6 Správa uˇzivatel˚u a oprávnˇen´ı . . . 55

5 Zhodnocen´ı a z´avˇer 57

A CD 60

B Seznam pouˇzit´ych zkratek 61

C N´avod na pouˇzit´ı projektu 62

(15)

Seznam obr´azk˚u

Seznam obr´

azk˚

u

1.1 Diagram projektu RTS2 UI. . . 18

3.1 Diagram vrstev navrˇzen´eho serveru. . . 28

3.2 Sch´ema datab´aze RTS2 UI. . . 39

4.1 Rozhran´ı RTS2 UI - seznam teleskop˚u. . . 41

4.2 Rozhran´ı RTS2 UI - seznam teleskop˚u pro veˇrejnost. . . 41

4.3 Rozhran´ı RTS2 UI - formul´aˇr pro spr´avu teleskopu. . . 42

4.4 Rozhran´ı aplikace rts2-mon. . . 43

4.5 Rozhran´ı RTS2 UI. . . 44

4.6 Rozhran´ı RTS2 UI - zobrazen´ı ˇcasu. . . 45

4.7 Rozhran´ı RTS2 UI - zobrazen´ı bˇeˇzn´ych datov´ych typ˚u. . . 45

4.8 Rozhran´ı RTS2 UI - zobrazen´ı logick´eho typu. . . 45

4.9 Rozhran´ı RTS2 UI - zobrazen´ı parametru typu pole. . . 46

4.10 Rozhran´ı RTS2 UI - zobrazen´ı parametru typu obd´eln´ık. . . 46

4.11 Rozhran´ı RTS2 UI - zobrazen´ı parametru typu objekt Alt Az souˇradnic. 46 4.12 Rozhran´ı RTS2 UI - zobrazen´ı aktu´aln´ıho sn´ımku. . . 47

4.13 Rozhran´ı RTS2 UI - seznam pozorovac´ıch c´ıl˚u. . . 49

4.14 Rozhran´ı RTS2 UI - editace pozorovac´ıho c´ıle. . . 50

4.15 Rozhran´ı RTS2 UI - formul´aˇr pro pˇrid´an´ı c´ıle do fronty. . . 52

4.16 Rozhran´ı RTS2 UI - tabulka pro zobrazen´ı front. . . 53

4.17 Rozhran´ı RTS2 UI - tabulka pro zobrazen´ı pl´anu. . . 53

4.18 Rozhran´ı RTS2 UI - zobrazen´ı obr´azk˚u podle z urˇcit´eho dne. . . 54

4.19 Rozhran´ı RTS2 UI - zobrazen´ı sn´ımk˚u podle pozorovac´ıho c´ıle. . . 55

4.20 Rozhran´ı RTS2 UI - seznam uˇzivatel˚u. . . 55

4.21 Rozhran´ı RTS2 UI - formul´aˇr uˇzivatele. . . 56

(16)

Seznam k´od˚u

Seznam K´

od˚

u

3.1 Oblast pro zobrazen´ı layout˚u. . . 28

3.2 Definice modulu ’app’. . . 28

3.3 Centráln´ı ˇreˇsen´ı poˇzadavk˚u a odpovˇed´ı klientské ˇcásti. . . 29

3.4 Smˇerován´ı v klientské ˇcásti. . . 30

3.5 Definice modulu. . . 30

3.6 Rozˇs´ıˇren´ı modulu. . . 30

3.7 Pouˇzit´ı kontroleru. . . 31

3.8 Uk´azka metody servisu. . . 32

3.9 Zapouzdˇren´ı obsluhy HTTP ˇz´adosti. . . 36

3.10 Metoda pro obsluhu poˇzadavku na uloˇzen´ı uˇzivatele. . . 36

3.11 Hlavn´ı metoda filtru pro tokenovou autorizaci poˇzadavku. . . 37

4.1 Pˇr´ıkaz pro pˇrid´an´ı pozorovac´ıho c´ıle do fronty. . . 51

(17)

Seznam tabulek

3.1 Seznam z´avislosti na ostatn´ıch knihovn´ach. . . 33

4.1 Metoda pro z´ısk´an´ı seznamu zaˇr´ızen´ı syst´emu RTS2. . . 44

4.2 Metoda pro z´ısk´an´ı parametr˚u zaˇr´ızen´ı. . . 44

4.3 Metoda pro uloˇzen´ı parametru zaˇr´ızen´ı. . . 47

4.4 Metoda pro z´ısk´an´ı souˇcasn´eho sn´ımku. . . 48

4.5 Metoda pro spuˇstˇen´ı expozice u zaˇr´ızen´ı typu kamera. . . 48

4.6 Metoda pro z´ısk´an´ı seznamu vˇsech pozorovac´ıch c´ıl˚u. . . 49

4.7 Metoda pro z´ısk´an´ı seznamu specifick´ych pozorovac´ıch c´ıl˚u. . . 49

4.8 Metoda pro z´ısk´an´ı informac´ı o konkr´etn´ım pozorovac´ım c´ıli. . . 50

4.9 Metoda pro vytvoˇren´ı pozorovac´ıho c´ıle. . . 51

4.10 Metoda pro ´upravu pozorovac´ıho c´ıle. . . 51

(18)

(19)

Kapitola 1 - ´Uvod

1. ´

Uvod

Jiˇz nˇekolik let pracuji pro komerˇcn´ı sféru jako webový vývojáˇr, i se sám o webové technologie zaj´ımám. Jsem tedy rád za moˇznost uplatnˇen´ı tˇechto znalost´ı v závˇereˇcné práci, která se týká tohoto smˇeru a jeˇstˇe zaj´ımavˇejˇs´ıho prvku, a t´ım je pozorován´ı vesm´ıru.

´

Uˇcelem této práce je vytvoˇren´ı webového rozhran´ı, které zpˇr´ıstupn´ı moˇznosti ob-servatoˇre. Observatoˇr´ı bude moˇznost do systému pˇridat v´ıce a centrálnˇe je spravovat. Bude moˇzné provádˇet základn´ı úkony, které potˇrebuj´ı vˇedci pro obsluhu observatoˇre, jako správa zaˇr´ızen´ı a nastavován´ı parametr˚u, správa c´ıl˚u pozorován´ı, moˇznost po-zorovat, pˇr´ıstup k napozorovaným dat˚um a dalˇs´ı. Observatoˇre, které p˚ujdou do centráln´ıho systému pˇridat, mus´ı pouˇz´ıvat systém RTS2 [6].

Protoˇze název práce je trochu delˇs´ı, tak jsem tuto práci, ˇci softwarový projekt, nazval RTS2 UI, jako navázán´ı na projet RTS2, který podrobnˇeji popisuji v sekci 2.1 a zkratka UI znamená uˇzivatelské rozhran´ı z anglického User Interface. Konkrétnˇe se bude jednat o webové uˇzivatelské rozhran´ı, o které se RTS2 UI snaˇz´ı p˚uvodn´ı projekt RTS2 rozˇs´ıˇrit.

Práce má za úkol praktickou implementaci rozhran´ı pro uˇzivatele, které bude umoˇzˇnovat snadnou správu a ovládán´ı, také nab´ıdne vyˇsˇs´ı nadhled. Pro zaˇcátek bych uvedl, ˇze projekt RTS2 je zjednoduˇsenˇe ˇreˇseno software, který zajiˇst’uje chod observatoˇre jak z pohledu hardwaru, tak s moˇznost´ı plánovat a vzdálenˇe pozorovat chován´ı observatoˇre. Nechyb´ı mu ani moˇznost autonomn´ıho pozorován´ı. Projekt RTS2 umoˇzˇnuje mnoho vˇec´ı, ale chyb´ı mu centráln´ı jednoduchý nadhled nad v´ıce observatoˇremi.

1.1 Popis poˇ

zadavk˚

u pr´

ace

Samotný projekt RTS2 je vedený pod licenc´ı LGPL. Ovladaˇce, které jiˇz tento pro-jekt zahrnuje jsou vedeny pod GPL licenc´ı. I softwarový projekt RTS UI mus´ı m´ıt otevˇrený zdrojový kód.

Pokusy o vytvoˇren´ı obdobného softwaru v minulosti jiˇz byly, napˇr´ıklad ve zdroji [5]. Podle dostupných informac´ı a provedené analýzy jim chyb´ı flexibiln´ı generován´ı poˇzadavk˚u. Umoˇzˇnuj´ı uˇzivatel˚um mˇenit jisté zpˇr´ıstupnˇené parametry, ale obvykle jen pomoc´ı specifických metod, coˇz nen´ı moc praktické. Pokud by se napˇr´ıklad zmˇenil název promˇenné zaˇr´ızen´ı nebo celé zaˇr´ızen´ı, tak by jiˇz takto ruˇcnˇe napsaný kód ne-mohl fungovat a musel by se opˇet pˇrizp˚usobit nové zmˇenˇe dalˇs´ım ruˇcn´ım pˇrepsán´ım. Z toho vyplývá, ˇze jedn´ım z hlavn´ıch poˇzadavk˚u softwarového projektu RTS2 UI je, aby umˇel generovat poˇzadavky podle dostupných dat o zaˇr´ızen´ı pˇrizp˚usobivˇe, dle aktuáln´ıch informac´ı.

Dalˇs´ım bodem je oprávnˇen´ı uˇzivatel˚u. Projekt RTS2 samotný poskytuje auto-rizace k poˇzadavk˚um pomoc´ı protokolu HTTP. Ovˇeˇren´ı funguje pouze na lokáln´ı observatoˇr a m˚uˇze nastavit uˇzivateli oprávnˇen´ı zacházet se zaˇr´ızen´ımi. Pro potˇreby

(20)

Kapitola 1 - ´Uvod

Obr´azek 1.1: Diagram projektu RTS2 UI.

centralizovaného pˇr´ıstupu jako u projektu RTS2 UI bude potˇreba vytvoˇrit r˚uzná oprávnˇen´ı a správu uˇzivatel˚u. Uvaˇzovaná oprávnˇen´ı jsou administrátor, vˇedec a ve-ˇrejný úˇcet. Kdy administrátor má m´ıt moˇznost provádˇet vˇsechny akce. Oprávnˇen´ı vˇedce by umoˇzˇnovalo provádˇet úkony týkaj´ıc´ı se jednotlivých dalekohled˚u. A veˇrejný ´

uˇcet by umoˇznil plánovat pozorován´ı pouze v ˇcasech, kdy si observatoˇr vyhlás´ı veˇrejnˇe pˇr´ıstupné hodiny.

Aby uˇzivatelé mohli plánovat pozorován´ı, bude nutné zpˇr´ıstupnit správu pozo-rovac´ıch c´ıl˚u. Pozorovac´ı c´ıl je bod na obloze, jehoˇz souˇradnice se uloˇz´ı spoleˇcnˇe s pojmenován´ım a dalˇs´ımi parametry do databáze. Pozorovac´ı c´ıle jsou na kaˇzdé ob-servatoˇri vedeny jinak, tj. stejné souˇradnice na obloze mohou m´ıt jinou identifikaci v databázi, ˇci jiný název.

Observatoˇre se systémem RTS2 umoˇzˇnuj´ı automatické vykonávan´ı plánu. Správa plánu bude pˇr´ıstupná i z projektu RTS2 UI. Plán je realizován za pomoc´ı pˇr´ıstupu front, z kterých se podle priority a vhodnosti c´ıle vyb´ırá. Centráln´ı systém mus´ı umˇet tyto fronty spravovat.

Nakonec je potˇreba umˇet k uˇzivateli dostat výsledek pozorován´ı. Sn´ımky jsou uchovávány v kaˇzdé observatoˇri zvláˇst’. Nˇekteré observatoˇre, vzhledem k jejich po-loze, maj´ı pomalejˇs´ı pˇripojen´ı k internetu. Bude tedy vhodné vytvoˇrit centráln´ı pˇr´ıstup k napozorovaným sn´ımk˚um s ohledem na odlehˇcen´ı toku dat mezi observatoˇr´ı a centráln´ım serverem.

(21)

Kapitola 1 - ´Uvod

1.2 Motivace

Systém RTS2 nab´ız´ı správu observatoˇre pomoc´ı HTTP protokolu, konzolových apli-kac´ı a jednoduchého webu, který sp´ıˇse ukazuje informace o stavu. Vzhledem k asoci-ativn´ımu myˇslen´ı lid´ı je lepˇs´ı, kdyˇz vid´ı moˇznosti, neˇz ruˇcn´ı psan´ı pˇr´ıkaz˚u z pamˇeti. Doufám v praktické pouˇzit´ı projektu vˇedci a dalˇs´ımi lidmi, kterým takovýto interface m˚uˇze ulehˇcit práci.

Dále pak centralizovaný pˇr´ıstup m˚uˇze nab´ıdnout lepˇs´ı pˇrehled nad jiˇz napo-zorovanými daty nebo nad celkovým plánem s´ıtˇe observatoˇr´ı. Coˇz m˚uˇze otevˇr´ıt cestu dalˇs´ım modul˚um projektu, které mohou provádˇet napˇr´ıklad statistické analýzy sn´ımk˚u nebo vylepˇsovat metody plánován´ı pozorován´ı centrálnˇe v s´ıti observatoˇr´ı.

V neposledn´ı ˇradˇe je zaj´ımavou motivac´ı zpˇr´ıstupnˇen´ı observatoˇre veˇrejnosti. Protoˇze jsou nˇekteré observatoˇre financovány z veˇrejných penˇez, maj´ı povolený pˇr´ıstup pro veˇrejnost v urˇcitých hodinách.

1.3 Zdroje pro pr´

aci

Hlavn´ım zdrojem pro práci je dokumentace a zdrojový kód projetu RTS2. Vˇse je dostupné ve zdroj´ıch [6] a [1]. Zdroj [6] je webová stránka projektu, kde je k nalezen´ı popis a zdrojový kód. Zdroj [1] je dokument popisuj´ıc´ı r˚uznou funkcionalitu a hlavnˇe HTTP rozhran´ı.

Pro tvorbu softwaru vyuˇziji své znalosti. Protoˇze jsou hlavnˇe z komerˇcn´ı sféry, budu muset naj´ıt vhodné alternativy, které mi umoˇzn´ı vytvoˇrit podobné ˇreˇsen´ı.

(22)

(23)

Kapitola 2 - Anal´yza

2. Anal´

yza

2.1 Remote Telescope System 2

Remote Telescope System 2 (RTS2) je projekt, na který navazuji. Zajiˇst’uje stan-dardn´ı rozhran´ı pro komunikaci s observatoˇr´ı. Je velmi rozsáhlý. Zahrnuje abstraktn´ı tˇr´ıdy pro zaˇr´ızen´ı, modulárn´ım pˇr´ıstupem implementuje r˚uzné servisn´ı sluˇzby jako plánovaˇc, vykonávaˇc pozorován´ı, sluˇzba BigBrother zajiˇst’uje plánován´ı mezi v´ıce te-leskopy zároveˇn a dalˇs´ı sluˇzby. A hlavnˇe je navrˇzen pro samostatný bˇeh observatoˇre. Tato práce nejv´ıce vyuˇzije HTTP server, který poskytuje komunikaˇcn´ı rozhran´ı mezi observatoˇr´ı a standardn´ım HTTP klientem. Projekt RTS2 má otevˇrený zdro-jový kód, tedy je dostupný a dá se volnˇe rozˇsiˇrovat a upravovat. Jazyk tohoto pro-jektu je hlavnˇe C/C++. Dále jsou r˚uzné doplˇnkové skripty napsány v Pythonu. A pouAhaˇzitá databáze je PostgreSQL. Projekt je velice rozsáhlý, a proto dále uvedu pouze informace, které budu vyuˇz´ıvat. V´ıce informac´ı o projektu se nacház´ı na webové stránce ze zdroje [6].

2.1.1 JSON API

Projekt RTS2 UI bude komunikovat s jednotlivými observatoˇremi, které pouˇz´ıvaj´ı RTS2 systém pomoc´ı HTTP protokolu. RTS2 zajiˇst’uje komunikaci pomoc´ı HTTPD servisu. Servis oˇcekává poˇzadavky vyuˇz´ıvaj´ıc´ı metodu GET, neboli snadno for-mulovatelné pomoc´ı URL adresy. Kaˇzdý poˇzadavek mus´ı být autorizován HTTP ovˇeˇren´ım uˇzivatele, a to pomoc´ı jména a hesla. Pokud je poˇzadavek úspˇeˇsný, server odpov´ıdá kódem 2XX, v opaˇcném pˇr´ıpadˇe se pouˇzije kód 4XX. Server vrac´ı data ve formátu JSON v tˇele odpovˇedi, kde m˚uˇze být výsledek dotazu nebo chybová hláˇska. Informace, jak správnˇe formulovat poˇzadavky pro RTS2 observatoˇr, jsou z ˇcásti ve zdroji [1]. Dokument je vˇsak neúplný, obsahuje ˇradu chyb a neaktuálnost´ı. Dalˇs´ım zdrojem je pak samotný zdrojový kód, který je dostupný na serveru GitHub a od-kaz je ve zdroji [10]. Ten nen´ı obvykle opatˇren komentáˇri a ani intuitivn´ımi názvy vstupn´ıch promˇenných do poˇzadavk˚u, coˇz zp˚usobuje problém pˇri napojen´ı dalˇs´ıch projekt˚u jako RTS2 UI. Konkrétn´ı metody pouˇzité k realizaci budou popsány v ka-pitole 4, kde je i vysvˇetlen´ı pouˇzit´ı.

2.1.2 Pˇ

r´ıstup k napozorovan´

ym dat˚

um

Napozorovaná data, jsou dostupná pomoc´ı protokolu HTTP. Soubory jsou uloˇzeny na disku a RTS2 systém umoˇzˇnuje procházet úloˇziˇstˇe observatoˇre, na kterém soft-ware bˇeˇz´ı.

Zp˚usoby vyˇcten´ı dat jsou r˚uzné. Je moˇznost zobrazit pˇr´ımo data fyzicky v ad-resáˇrové struktuˇre, která je tvoˇrena podsloˇzkami pojmenovanými podle dat, kdy jsou sn´ımky, které se ve sloˇzce nacház´ı, poˇr´ızeny. Dalˇs´ı zp˚usoby jsou zobrazen´ı sn´ımku konkrétn´ıho pozorovac´ıho c´ıle nebo sn´ımk˚u konkrétn´ıho jiˇz probˇehlého pozorován´ı.

(24)

Systém RTS2 disponuje rozˇs´ıˇren´ım, které podle souˇradnic sn´ımku dokáˇze urˇcit, jestli je sn´ımek dobrý. Automaticky pak tˇr´ıd´ı sn´ımky, které jsou pˇreexponované nebo rozmazané.

Systém RTS2 poskytuje nˇekolik formát˚u sn´ımku. Pˇri dotazu na souˇcasný sn´ımek je formát binárn´ı a struktura byla nalezena ve zdrojovém kódu. Dále standardn´ı formát JPEG, jak pro náhledy, tak pro sn´ımky plného rozliˇsen´ı. A hlavn´ım astro-nomickým formátem je FITS [9], který obsahuje i r˚uzná metadata o pozorován´ı. Sn´ımky sou ˇcernob´ılé s vˇetˇs´ı bitovou hloubkou na jeden pixel, konkrétnˇe 12 bit, coˇz se pˇrevede do 16 bit promˇennéshort.

2.2 Anal´

yza souˇ

casn´

ych projekt˚

u

Podobné softwarové ˇreˇsen´ı jiˇz vzniklo v rámci diplomové práce. Práce byla v´ıce zamˇeˇrena na ovládán´ı jedné observatoˇre se systémem RTS2 pomoc´ı mobiln´ı aplikace. Název práce je

”Mobiln´ı aplikace pro ˇr´ızen´ı v reálném ˇcase“ a autorem je Jan ˇSára. Lze ji naj´ıt v referenci [5].

Práce vol´ı jako hlavn´ı jazyk JavaScript. Ten je vyuˇzit jak pro klientskou ˇcást, tak pro serverovou ˇcást. Pro projekt RTS2 UI nepovaˇzuji tuto volbu pro serve-rovou ˇcást za vhodnou. Nev´ım, jestli se v JavaScriptu daj´ı ˇreˇsit r˚uzné problémy, napˇr´ıklad v´ıce vláknová obsluha nebo r˚uzné servisy. Jazyk Java toto urˇcitˇe um´ı a nen´ı problém jej vyuˇzit. Disponuje mnoˇzstv´ım knihoven, d´ıky kterým si programátor m˚uˇze ulehˇcit práci. JavaScript na serverové ˇcásti urˇcitˇe nen´ı tak rozˇs´ıˇrený. To zna-mená, ˇze i mnoˇzstv´ıˇreˇsených problém˚u bude menˇs´ı a v pˇr´ıpadˇe nˇejakého specifického poˇzadavku to m˚uˇze být neˇreˇsitelné za pomoci standardn´ıho postupu. V neposledn´ı ˇradˇe bych odhadoval, ˇze Java bude i efektivnˇejˇs´ı neˇz JavaScript z hlediska výkonu.

Dále práce pouˇz´ıvá MongoDB databázi. Je to zˇrejmˇe výhodná volba pˇri pouˇzit´ı právˇe s programovac´ım jazykem JavaScript. Databáze MongoDB ukládá data ve formátu JSON v binárn´ı podobˇe. JavaScript nepotˇrebuje pˇretypovávat nebo vytváˇret dotazy, ale staˇc´ı data jen naˇc´ıtat a ukládat. Zˇrejmˇe práce nevyuˇz´ıvá ani referenˇcn´ı integrity dat, protoˇze MongoDB nen´ı relaˇcn´ı databáz´ı. Projekt RTS2 UI bude m´ıt urˇcitˇe pevnou strukturu dat s potˇrebou zachován´ı referenˇcn´ı integrity. Proto byla radˇeji vybrána relaˇcn´ı databáze PostgreSQL.

Pˇri analýze pouˇzitých HTTP metod od systému RTS2, které vyuˇz´ıvá práce, bych odhadoval, ˇze nen´ı realizována s ohledem na generován´ı formuláˇr˚u a poˇzadavk˚u podle aktuáln´ıch informac´ı. Zpˇr´ıstupnˇené kontroln´ı prvky výsledné aplikace také napov´ıdaj´ı, ˇze umoˇzˇnuje jen proveden´ı nˇekterých úkon˚u. V pˇr´ıpadˇe zmˇeny parametr˚u se pravdˇepodobnˇe bude muset pˇrepsat znovu. Proto jsem se nemohl inspirovat ani v klientské ˇcásti aplikace pro generován´ı formuláˇr˚u. Robustnost ˇreˇsen´ı je jedn´ım z hlavn´ıch c´ıl˚u RTS2 UI.

Práce mˇe inspirovala okrajovˇe v tom, ˇze i RTS2 UI m˚uˇze být mobiln´ı aplikac´ı. Vzhledem ke zvolené vzhledové knihovnˇe Bootstrap je toto realizováno snadno, ale nen´ı na to brán primárn´ı ohled. Je moˇzné, ˇze nˇeco nebude správnˇe zarovnané. Hlavn´ı myˇslenka mobiln´ı verze je, ˇze se prvky, které jsou v ˇrádku vedle sebe, maj´ı schopnost

(25)

pˇri zúˇzen´ı obrazovky pˇreskupit pod sebe. To ulehˇc´ı práci uˇzivateli, který pak nebude muset posouvat okno v horizontáln´ım smˇeru, ale pouze ve vertikáln´ım. Rovnˇeˇz se t´ımto prvek nepatrnˇe zvˇetˇs´ı a je pak snadnˇeji ovladatelný na menˇs´ı obrazovce.

2.3 V´

ybˇ

er technick´

eho pozad´ı

2.3.1 Typ komunikace server - klient

Aktuáln´ıch dostupných webových technologi´ı je dnes spousta. Daj´ı se pouˇz´ıt r˚uzné architektury a styl komunikace mezi klientem a serverem. Nejznámˇejˇs´ımi technikami jsou pravdˇepodobnˇe MVC nebo SPA+BackEnd, které jsem také uvaˇzoval a dále je rozeberu.

MVC

MVC je zkratka z anglického Model View Controller a znamená styl, kdy je propo-jen pohled uˇzivatele pˇr´ımo s kódem serveru. Hlavn´ımi zástupci tohoto pˇr´ıstupu jsou skriptovac´ı jazyk PHP, pro jazyk Java je to pak technologie JSP a napˇr´ıklad pro C# ˇci VisualBasic je to technologie ASP.NET. Nevýhodou tohoto pˇr´ıstupu jsou hlavnˇe v minulosti naprogramované aplikace, které v jednom zdrojovém kódu kombinovaly v´ıce jazyk˚u. Napˇr´ıklad PHP vygeneruje HTML stránku s JavaScriptem a CSS sty-lem. Dneˇsn´ı názor je, ˇze je to nepˇrehledné a zastaralé. Existuj´ı r˚uzné pˇripravené knihovny ˇci rámce (frameworks), které práci usnadˇnuj´ı a snaˇz´ı se tento pˇr´ıstup co nejv´ıce zjednoduˇsit. Pro jazyk PHP je to napˇr´ıklad projekt Laravel.

SPA + BackEnd

Druhý uvaˇzovaný pˇr´ıstup je SPA + BackEnd. SPA znaˇc´ı klientskou ˇcást aplikace a BackEnd je serverová ˇcást. Tyto dvˇe ˇcásti mezi sebou vzájemnˇe komunikuj´ı. Na prvn´ı pohled moˇzná zdánlivˇe m˚uˇzou naznaˇcovat sloˇzitˇejˇs´ı pˇristup, pˇreci jen vývoj dvou aplikac´ı m´ısto jedné by mˇel být sloˇzitˇejˇs´ı. Nen´ı to ale tak moc znatelné a nab´ız´ı to v´ıce výhod neˇz MVC pˇr´ıstup.

SPA je z anglického Single Page Application. Pˇreklad z angliˇctiny, tj. aplikace v samostatné stránce, je výstiˇzný. Vztahuje se to pouze na klientskou ˇcást webové aplikace. Ta funguje tak, ˇze pˇri poˇzadavku od uˇzivatele na server se jako prvn´ı krok provede poslán´ı právˇe této klientské SPA ˇcásti aplikace. Klientskou ˇcást má uˇzivatel naˇctenou pouze jednou a pak uˇz m˚uˇze pˇristupovat k dalˇs´ım informac´ım pouze prostˇrednictv´ım klientské ˇcásti. Pˇr´ıstup SPA má nˇekolik hlavn´ıch výhod. Prvn´ı je, ˇze se nemusej´ı neustále pos´ılat zbyteˇcné informace jako HTML formátován´ı, CSS styly ˇci JavaScriptové ˇcásti, ale poˇzaduj´ı se po serveru pouze ˇcistá data. Coˇz je výhodné z hlediska rychlosti naˇc´ıtan´ı a objemu pˇrenáˇsených dat. Druhá hlavn´ı výhoda je, ˇze se tatoSPAˇcást napojuje pomoc´ı HTTP protokolu a napˇr´ıklad REST API, coˇz umoˇzn´ı napojen´ı jiných klient˚u v budoucnu. Pokud se projekt rozˇs´ıˇr´ı a bude potˇreba vytvoˇrit napˇr´ıklad aplikaci pro mobiln´ı platformu, nemus´ı se celá logika ser-veru programovat znovu, ale vyuˇzije se stávaj´ıc´ı. Staˇc´ı pouze schopnost klientské

(26)

ˇ

cásti komunikovat pomoc´ı protokolu HTTP, coˇz zvládá prakticky kaˇzdý jazyk. Dalˇs´ı výhodou je zamˇenitelnost ˇcást´ı aplikace. Jak jiˇz bylo zm´ınˇeno, klientská ˇcást m˚uˇze být zpˇr´ıstupnˇena pro r˚uzné jazyky, a t´ım i pro jiné platformy, at’ uˇz web, Android, Windows, Mac a dalˇs´ı.

BackEndová neboli serverová ˇcást aplikace je potom realizovaná samostatnˇe, a to jednoduchým pˇr´ıstupem, kdy se definuje pouze zp˚usob autorizace, vstupn´ı data pro poˇzadavek a pak výstupn´ı data poˇzadavku. Serverová ˇcást m˚uˇze být opˇet v jakémkoliv jazyce, který um´ı poskytovat komunikaci pˇres HTTP protokol pro ser-ver. Dobrý výbˇer jazyka pro tuto ˇcást je vcelku podstatný. Bylo by sice hezké m´ıt co nejmenˇs´ı nároky na server a zvolit pokud moˇzno jazyk C, ale bohuˇzel to znaˇcnˇe znepˇrehledn´ı kód a neposkytuje takové výhody jako ostatn´ı, napˇr´ıklad interpreto-vané jazyky.

2.3.2 V´

ybˇ

er konkr´

etn´ıch technologi´ı

Klient

Jak pro klientskou ˇcást, tak i pro serverovou existuj´ı komerˇcn´ı i nekomerˇcn´ı ˇreˇsen´ı. Vzhledem k tomu, ˇze projekt RTS2 UI by mˇel být otevˇrený, vyuˇziji pouze otevˇrené knihovny. Pro výbˇer webové klientské ˇcásti jsem zvolil framework AngularJS. Je to JavaScriptový framework, který poskytuje snadnou a srozumitelnou architekturu a na vývoji se pod´ıl´ı komunita vývojáˇr˚u spoleˇcnˇe s firmou Google. JavaScript sa-motný poskytuje HTTP rozhran´ı pro komunikaci se serverem. A dneˇsn´ı webové prohl´ıˇzeˇce podporuj´ıc´ı HTML 5 standard umoˇzˇnuj´ı mnoho dalˇs´ıho. Podpora HTML 5 bude urˇcitˇe hlavn´ı pˇredpoklad pro korektn´ı funkci aplikace. Pouˇziji styl knihovny Boostrap, který zajist´ı, ˇze aplikace bude m´ıt estetický a standardn´ı vzhled. Pro uzp˚usoben´ı vzhledu jsou dostupné r˚uzné styly v pˇr´ıpadˇe potˇreby. Tato stylová kni-hovna nen´ı pouze o jednoduchosti vzhledu, ale pˇri správném pouˇzit´ı um´ı zajistit korektn´ı zobrazen´ı na r˚uzných zaˇr´ızen´ıch jako tablety a mobiln´ı telefony.

Server

U serverové ˇcásti webových aplikac´ı se dá s výhodou pouˇz´ıt pˇr´ıstup aplikaˇcn´ıch server˚u, které implementuj´ı kontejnerovou logiku. Tento pˇr´ıstup má nˇekolik výhod a nevýhod. Protoˇze se aplikace publikuje po ˇcástech, m˚uˇze na jednom serveru a stej-ném portu bˇeˇzet v´ıce r˚uzných aplikac´ı. R˚uzné ˇcásti budou m´ıt pak pouze jiné smˇerován´ı na zaˇcátku URL adresy napˇr´ıklad jako

h t t p : / / app1 . s e r v e r / nebo h t t p : / / s e r v e r / app1 / h t t p : / / app2 . s e r v e r / nebo h t t p : / / s e r v e r / app2 / .

Také u produkˇcn´ıho prostˇred´ı jsou zˇrejmé výhody v tom, ˇze nen´ı nutné vypnout dalˇs´ı ˇ

cásti ˇci celé aplikace, pokud potˇrebujete nahrát novou verzi aplikace. V neposledn´ı ˇradˇe tento pˇr´ıstup umoˇzˇnuje centralizovanou správu konfigurace serveru pro vˇsechny aplikace. Správa SSL certifikát˚u a r˚uzné dalˇs´ı nastaven´ı se ˇreˇs´ı pomoc´ı konfigurace serveru a nemus´ı se o to starat programátor aplikace.

(27)

Nevýhodou tohoto pˇr´ıstupu je, ˇze mus´ıte m´ıt aplikaˇcn´ı server a mus´ıte jej správnˇe nakonfigurovat. Aplikace mus´ı být kompatibiln´ı s verz´ı serveru. Jsou zde jak ko-merˇcn´ı ˇreˇsen´ı jako je ISS server od Microsoftu, tak otevˇrené ˇreˇsen´ı jako je TomCat server od Apache. Urˇcitý problém je také v tom, ˇze pokud je server otevˇrený, m˚uˇze být lehce zkoumán útoˇcn´ıky. Na starˇs´ı a neaktualizované verze serveru se objevuj´ı bˇeˇznˇe útoky, které dokáˇzou zpˇr´ıstupnit útoˇcn´ıkovi data a kontrolu nad serverem. Pro pouˇzit´ı aplikaˇcn´ıho serveru je nutné jej udrˇzovat neustále aktuáln´ı.

Pro projekt RTS2 UI jsem zvolil jednoduchý HTTP server bez kontejnerové lo-giky. D˚uvody jsou takové, ˇze pˇred pouˇzit´ım projektu nemus´ıte instalovat a konfigu-rovat jiný software. Obvykle nebývá u takovýchto projekt˚u potˇreba, aby na jednom poˇc´ıtaˇci a jednom portu fungovalo nˇekolik aplikac´ı najednou a tud´ıˇz nen´ı nutné m´ıt výhody aplikaˇcn´ıho serveru. Projekt RTS2 implementuje server stejným zp˚usobem, tj. vyuˇz´ıvá jen základn´ıho objektu pro HTTP komunikaci a smˇerován´ı, naˇc´ıtán´ı vstupn´ıch dat a dalˇs´ı ˇreˇs´ı kód aplikace.

Pro serverovou ˇcást projektu RTS2 UI jsem se snaˇzil naj´ıt jednoduché ˇreˇsen´ı v jazyce C/C++. V tomto jazyce je napsaný projekt RTS2. Vyhledal jsem nˇekolik ˇreˇsen´ı v podobnˇe knihoven, protoˇze napˇr´ıklad smˇerován´ı poˇzadavk˚u se dá vyˇreˇsit elegantn´ım zp˚usobem a programátor to nemus´ı sám ˇreˇsit pomoc´ı analýzy textového parametru cesty poˇzadavku. Nejlepˇs´ı byla knihovna POCO [12], která umˇela základ protokolu HTTP a mnoho dalˇs´ıho, ale nezdálo se mi to z hlediska pˇrehlednosti dobré. Nakonec jsem se rozhodl zvolit jazyk Java. Projekt RTS2 UI je oddˇeleným systémem a nen´ı tak podstatné, jaký bude m´ıt jazyk, hlavnˇe kdyˇz bude kód pˇrehledný. Pˇrehlednost kódu zajist´ı i vývojové prostˇred´ı NetBeans, které ulehˇcuje pohyb v hi-erarchii metod a dalˇs´ı programátorské úkony.

2.3.3 Datab´

aze

Mezi databázovými systémy jsou aktuálnˇe dvˇe hlavn´ı volby, a to NoSQL databáze, které se pouˇz´ıvaj´ı pro velká data, a pak klasické relaˇcn´ı databáze. Protoˇze neoˇcekávám od projektu RTS2 UI zpracován´ı velkého objemu dat a je zˇrejmý databázový model, vyuˇziji radˇeji klasického relaˇcn´ıho pˇr´ıstupu databáz´ı. Relaˇcn´ı pˇr´ıstup nab´ız´ı i oˇsetˇren´ı vazeb mezi entitami, které bude u projektu RTS2 UI potˇreba. Konkrétnˇe byla vybrána databáze PostgreSQL, kterou vyuˇz´ıvá i projekt RTS2. Je volnˇe pouˇzitelná za dodrˇzen´ı podm´ınek licence MIT.

2.3.4 Administrace projektu

Pro jednoduchý vývoj projektu budou pouˇzity dvoje vývojová prostˇred´ı, a to NetBe-ans a Visual Studio Code. NetBeNetBe-ans umoˇzˇnuje pˇrehlednou tvorbu aplikac´ı v jazyce Java, um´ı i HTML 5 a JavaScript, ale pro tyto dva webové jazyky jsem radˇeji zvolil Visual Studio Code.

Kaˇzdý rozsáhlejˇs´ı projekt se neobejde bez systému na správu verz´ı. Pro tento ´

uˇcel jsem pouˇzil program git. Aby byl projekt dostupný, vyuˇziji sluˇzby GitHub, který umoˇzn´ı veden´ı repozitáˇre projektu zdarma.

(28)

Pro správu a vyuˇzit´ı ostatn´ıch knihoven potˇrebných k projektu vyuˇziji pro ser-verovou ˇcást Maven [16] a pro klientskou bower [17]. Obˇe aplikace jsou podobné. Umoˇzˇnuj´ı jednoduchá pˇridán´ı knihovny z repozitáˇre aplikace do projektu, také snad-nou zmˇenu na novˇejˇs´ı verzi a ˇreˇs´ı i závislosti jednotlivých knihoven.

(29)

Kapitola 3 - Popis zvolen´eho ˇreˇsen´ı

3. Popis zvolen´

eho ˇ

reˇ

sen´ı

Celý softwarový projekt je rozdˇelen do mnoha vrstev. Kaˇzdá z vrstev zajiˇst’uje urˇcitou specifickou funkcionalitu, kterou dále podrobnˇe vysvˇetl´ım. Základn´ı pˇred-stavu o rozvrˇzen´ı projektu lze z´ıskat z diagramu 3.1. Prvn´ı dva ˇrádky diagramu jsou pro vytvoˇren´ı nadhledu. Posledn´ı ˇrádek obsahuje jednotlivé podbloky, které jsou podrobnˇeji rozkresleny. Ale kaˇzdý ˇrádek diagramu pˇredstavuje to samé.

Celý softwarový projekt je dostupný na sluˇzbˇe portálu GitHub a konkrétn´ı odkaz naleznete v referenci [11] nebo lze vyuˇz´ıt tento pˇr´ıkaz:

g i t c l o n e h t t p s : / / g i t h u b . com/Ramese/ r t s 2 u i . g i t

Repozitáˇr je rozdˇelen na sloˇzku Database,Documentation aProject. Sloˇzka Da-tabase obsahuje SQL skript pro vytvoˇren´ı nové databáze k softwarovému projektu RTS2 UI. SQL skript by mˇel být kompatibiln´ı s PostgreSQL a byl vygenerován pomoc´ı programu pgAdmin. Sloˇzka Documentation obsahuje hlavnˇe text této práce a dále napˇr´ıklad dokumentaci k RTS2 JSON API ve formátu PDF, která ale nen´ı plnˇe korektn´ı, nicménˇe je to nejlepˇs´ı dostupná verze a byla pouˇzita pro vytvoˇren´ı nˇekteré funkcionality. Sloˇzka Project obsahuje zdrojový kód softwarového projektu RTS2 UI. Sloˇzku je moˇzno otevˇr´ıt ve vývojovém prostˇred´ı Netbeans s nainstalo-vaným rozˇs´ıˇren´ım Maven. Pro zkompilován´ı je nutné stáhnout závislosti projektu. AdresáˇrWeb, který se nacház´ı v adresáˇri Project, obsahuje soubory klientské ˇcásti projektu.

3.1 Klientsk´

a ˇ

c´

ast RTS2 UI

Jak bylo zm´ınˇeno v kapitole týkaj´ıc´ı se analýzy práce, pro klientskou ˇcást projektu byl vybrán JavaScriptový framework AngularJS, který je dostupný ze zdroje [13]. Dále klientská ˇcást vyuˇz´ıvá r˚uzné pˇridané knihovny jako projektUI Bootstrap, který doplˇnuje framework AngularJS o mnoho komponent, jako kalendáˇr, posuvn´ık atd. a je dostupný ze zdroje [15]. A dalˇs´ı pˇridané knihovny jakoFont-Awesome, Angular-Cookies, Angular-Route, atd.

AdresáˇrProject/Web nen´ı adresáˇrem, který by obsahoval metadata pro konkrétn´ı vývojové prostˇred´ı, lze pouˇz´ıt jakékoliv. Jediná metadata, která klientská ˇcást obsa-huje, jsou závislosti knihoven pro správu aplikac´ıbower aJSHint [18] pro udrˇzitelnost JavaScriptového kódu. Vˇsechny pouˇzité knihovny jsou pak k nalezen´ı v adresáˇri

Web/bower components.

3.1.1 Hlavn´ı soubor klienta - index.html

Hlavn´ım souborem, který naˇcte celou SPA aplikaci je soubor index.html. Ten naˇcte ze serveru vˇsechny skripty a styly, které pak vyuˇz´ıvá a nepotˇrebuje je stahovat znovu. Dále obsahuje základn´ı rozvrˇzen´ı stránky tj. vrchn´ı menu a kontejner náhled˚u pro

(30)

Obr´azek 3.1: Diagram vrstev navrˇzen´eho serveru.

vloˇzen´ı obsahu podle poˇzadavku. Obsah se vkládá do elementu div s definovaným atributem

”ng-view“ ve v´ypisu k´odu 3.1.

1 < div data - ng - v i e w c l a s s=" c o n t a i n e r - f l u i d "> </ div >

K´od 3.1: Oblast pro zobrazen´ı layout˚u.

3.1.2 Hlavn´ı soubor JS - app.js

Zaˇcátek JavaScriptové aplikace lze naj´ıt v souboruScripts/app.js. Ten definuje nový modul Angularu, a to modul nazvaný ’app’, pod kterým celá klientská ˇcást bˇeˇz´ı a navazuje dalˇs´ı ˇcásti aplikace. Specifikuje závislosti pˇridaných knihoven a dalˇs´ıch vytvoˇrených ˇcást´ı, jak je vidˇet v úseku kódu 3.2. Pouˇzit´ı tohoto modulu jako hlavn´ıho modulu klientské ˇcásti aplikace, je deklarováno v souboruindex.html v tagu

”<html data-ng-app=”app”>“.

1 var app = a n g u l a r . m o d u l e (’ app ’, [

2 // A N G U L A R S M O D U L E S : 3 ’ n g R o u t e ’, 4 ... 5 // 3 TH P A R T M O D U L E S : 6 ’ ui . b o o t s t r a p ’, 7 ... 8 // O U R S M O D U L E S : 28

(31)

9 ’ s e r v i c e s ’,

10 ’ c o n t r o l l e r s ’

11 ...

12 ]) ;

K´od 3.2: Definice modulu ’app’.

Aby JavaScriptový klient mohl být obslouˇzen serverem, mus´ı se správnˇe identifi-kovat. Identifikace prob´ıhá pomoc´ı tokenu. Kaˇzdý jeden poˇzadavek na server nejprve projde klientská ˇcást, která je vidˇet ve výpisu kódu 3.3. Tato ˇcást je zodpovˇedná za pˇridán´ı hlaviˇckové informace do HTTP poˇzadavku, a to konkrétnˇe

”Token“ a ” User-Name“. Tyto dvˇe informace jsou pouˇz´ıvány m´ısto neustálého pos´ılán´ı uˇzivatelského jména a hesla. Klient je z´ıská pˇri prvotn´ım pˇrihláˇsen´ı do aplikace. Token je serve-rovou ˇcást´ı vygenerovaný ˇretˇezec, který se nacház´ı v databázi a jeho platnost je osm hodin od posledn´ıho provedeného úkonu, aneb pˇri kaˇzdém poˇzadavku, který je platný, se jeho platnost prodluˇzuje o dalˇs´ıch osm hodin.

Tato technika autorizace je lepˇs´ı z d˚uvodu moˇznosti odchycen´ı zprávy mezi klien-tem a serverem. Pˇri pouˇzit´ı tokenové autorizace bude m´ıt útoˇcn´ık pouze token, který je platný po urˇcitou dobu. Samozˇrejmˇe hroz´ı odchycen´ı samotného hesla, a proto by se mˇel pouˇz´ıt protokol HTTPS, který pouˇz´ıvá asymptotické ˇsifrován´ı.

Token je spoleˇcnˇe s dalˇs´ımi informacemi uloˇzen v cookies souborech prohl´ıˇzeˇce. Výhodou uloˇzen´ı pouze tokenu a nikoliv jména a hesla je, ˇze tento mechanizmus zabraˇnuje i pˇr´ıpadným útok˚um s analýzou dat v cookies, kdy útoˇcn´ık pˇreˇcte sou-bor cookies z lokáln´ı stanice. M˚uˇze z´ıskat omezený pˇr´ıstup na konkrétn´ı dobu, ale napˇr´ıklad pˇri odhláˇsen´ı se token znehodnot´ı a útoˇcn´ık pˇr´ıstup ztrat´ı.

1 $ h t t p P r o v i d e r . i n t e r c e p t o r s . p u s h (f u n c t i o n ( $q , $ r o o t S c o p e , $window , $ t r a n s l a t e , C O N S T A N T S ) { 2 r e t u r n { 3 ’ r e q u e s t ’: f u n c t i o n ( c o n f i g ) { 4 if ( $ r o o t S c o p e . u s e r !== u n d e f i n e d ) { 5 c o n f i g . h e a d e r s . T o k e n = $ r o o t S c o p e . u s e r . T o k e n ; 6 c o n f i g . h e a d e r s . U s e r N a m e = $ r o o t S c o p e . u s e r . U s e r N a m e ; 7 } 8 r e t u r n c o n f i g ; 9 10 } , 11 ’ r e s p o n s e E r r o r ’: f u n c t i o n ( r e s p o n s e ) { 12 ... 13 // r e s p o n s e e r r o r c e n t r a l h a n d l e r 14 ... 15 } 16 }; 17 }) ;

Kód 3.3: Centráln´ı ˇreˇsen´ı poˇzadavk˚u a odpovˇed´ı klientské ˇcásti.

A dalˇs´ı ˇcást souboruapp.jsˇreˇs´ı smˇerován´ı pro klienta. Ve výpisu kódu 3.4 je vidˇet jedna definice smˇerován´ı. Kaˇzdá taková definice je pro jednu akci respektive jeden pohled do aplikace a urˇcuje cestu (

(32)

Views/inter-Kapitola 3 - Popis zvolen´eho ˇreˇsen´ı

face.html“), kontrol´er (

”InterfaceCtrl“), pˇr´ıstup (”freeAccess: false“) a nadpis (” In-terface RTS2 Web“). Specifikace cesty m˚uˇze obsahovat parametry jako je vidˇet zde ”:id“, kdy se pˇred´a parametr do kontrol´eru ”InterfaceCtrl“ pomoc´ı servisu $

route-Params.

Pˇr´ıstup ˇreˇs´ı toto smˇerován´ı pouze základnˇe, a to na úrovni jestli je uˇzivatel pˇrihláˇsen. Pokud nen´ı, odfiltruje rovnou zbyteˇcný poˇzadavek na server a poˇzádá uˇzivatele o pˇrihláˇsen´ı. Smˇerován´ı v klientské ˇcásti ˇreˇs´ı komponenta Angular-route

dostupn´a ze zdroje [14]. 1 $ r o u t e P r o v i d e r 2 . w h e n (’ / i n t e r f a c e /: id ’, { 3 t e m p l a t e U r l : ’ V i e w s / i n t e r f a c e . h t m l ’, 4 c o n t r o l l e r : ’ I n t e r f a c e C t r l ’, 5 f r e e A c c e s s : false, 6 t i t l e : " I n t e r f a c e R T S 2 Web " 7 })

Kód 3.4: Smˇerován´ı v klientské ˇcásti.

Klientsk´a ˇc´ast obsahuje jeˇstˇe dva dalˇs´ı hlavn´ı soubory a to Scripts/controllers.js

a Scripts/services.js. Závislost na tˇechto modulech je deklarována v ˇcásti kódu 3.2. Kaˇzdý modul m˚uˇze být rozˇs´ıˇren v separátn´ıch souborech. Napˇr´ıklad modul

” con-trollers“ je definován v souboruScripts/controllers.js (viz kód 3.5), ale jeho rozˇs´ıˇren´ı se nacház´ı v kaˇzdém ze soubor˚u nacházej´ıc´ıch se ve sloˇzce Scripts/Controllers (viz kód 3.6), tj. InterfaceCtrl.js,TelescopeCtrl.js, UserCtrl.js apod.

1 a n g u l a r . m o d u l e (’ c o n t r o l l e r s ’, [])

K´od 3.5: Definice modulu.

1 a n g u l a r . m o d u l e (’ c o n t r o l l e r s ’)

K´od 3.6: Rozˇs´ıˇren´ı modulu.

Hranaté závorky znaˇc´ı definici modulu a zároveˇn deklaraci závislost´ı, pokud by byly pouˇzity na v´ıce m´ıstech nebo v r˚uzných souborech, budou neustále modul definovat znovu a ztrat´ı pˇredchoz´ı funkcionalitu. V projektu RTS2 UI jsou takto vytvoˇreny pouze dva moduly, a to moduly

”services“ a ”controllers“.

3.1.3 Kontrolery

Klientsk´e kontrolery pˇredstavuj´ı v diagramu 3.1 blok s n´azvem

”Controllers“. Tato ˇ

cást obsahuje logiku, která je ukrytá na pozad´ı kaˇzdého náhledu, tj. pˇri zobrazen´ı formuláˇre pro pˇridán´ı teleskopu, logika pro obslouˇzen´ı událost´ı formuláˇre je právˇe v jednom z kontroler˚u. V tomto pˇr´ıpadˇe je to kontrolerControllers/TelescopeCtrl.js. Kontrolery jsou v projektové sloˇzce webové ˇcásti obsaˇzeny ve sloˇzce Scripts/Cont-rollers a v souboruScripts/controllers.js.

Kaˇzdý kontroler obsahuje své pamˇet’ové m´ısto v promˇenné$scope, které je obou-smˇernˇe provázáno s pohledem uˇzivatele. Kontrolery umoˇzˇnuj´ı hierarchické uskupen´ı

(33)

pod sebe do stromové struktury. Nejvyˇsˇs´ı kontroler v této aplikaci je NavCtrl, který je definovaný pro celý dokument HTML v tagu body, jak je vidˇet v úseku kódu 3.7.

NavCtrl zajiˇst’uje spoleˇcné funkce pro aplikaci, jako urˇcen´ı role uˇzivatele, a jeho prostor je dostupný ze vˇsech pod kontroler˚u. Pˇr´ıstup do kontroleru, který je v hi-erarchii výˇse, je realizován pomoc´ı poskytovaného servisu $scope. Ten pˇri zavolán´ı na neexistuj´ıc´ı promˇennou nebo funkci v m´ıstn´ım pamˇet’ovém prostoru automaticky zkus´ı zjistit, jestli nadˇrazený kontroler implementuje tuto funkci, a pokud ano, rov-nou ji vykoná.

1 < b o d y data - ng - c o n t r o l l e r =" N a v C t r l ">

K´od 3.7: Pouˇzit´ı kontroleru. ´

Ukolem kontroleru je zpracován´ı dat od uˇzivatel˚u. Jsou v nˇem definovány funkce pro oˇsetˇren´ı ˇspatných vstup˚u nebo pˇr´ıpadnˇe transformace dat do vhodného objektu JSON. Následnˇe komunikuje s nˇekterým z jiných kontroler˚u nebo pouˇzije servis pro komunikaci se serverovou ˇc´ısti, kde opˇet m˚uˇze z´ıskaná data zpracovat do podoby pro uˇzivatele, jako napˇr´ıklad pˇreveden´ı poˇctu sekund od data 1.1.1970 na klasický datový formát.

Jedn´ım z kontroler˚u je Error404Ctrl obsaˇzený v souboru Scripts/controllers.js. Tento zajiˇst’uje odpovˇed’ na ˇspatné volán´ı neexistuj´ıc´ıch cest aplikace, tedy server nemus´ı obsluhovat ani takovéto volán´ı.

3.1.4 Rozloˇ

zen´ı

Rozloˇzen´ı aktuáln´ıho pohledu je definováno v klasických souborech HTML. Ad-resáˇr Views obsahuje vˇsechny rozvrˇzen´ı aplikace. Podle cesty v adresovém ˇrádku se pouˇzije vhodné rozvrˇzen´ı dle definice v souboru app.js jako je ve výpisu kódu 3.4. Poˇzadované rozvrˇzen´ı se um´ıst´ı do tagu v kódu 3.1 nebo pˇr´ıpadnˇe do konkrétn´ı specifické ˇcásti aplikace jako m˚uˇze být definovaná direktiva nebo atributng-include. Kaˇzdé rozloˇzen´ı definuje vzhled dané ˇcásti a pouˇzit´ı promˇenných z prostoru kon-troleru. Rozloˇzen´ı je s kontrolerem provázáno pomoc´ı servisu $scope. Také definuje omezen´ı vstupu uˇzivatele a pˇr´ıpadné varován´ı, ˇze by vstup mˇel být opraven. K tˇemto definic´ım se vyuˇz´ıvaj´ı atributy frameworku AngularJS zaˇc´ınaj´ıc´ı na

”ng-...“ nebo ”data-ng-...“ a také vzhledové knihovny Bootstrap. Je i moˇzné definovat a pouˇz´ıt své atributy nebo tˇr´ıdy.

3.1.5 Servisy

Servis v této aplikaci zajiˇst’uje pˇreváˇznˇe komunikaci se serverovou ˇcást´ı, ale m˚uˇze zajiˇst’ovat komunikaci mezi kontrolery nebo napˇr´ıklad jako zde pouˇzitý servis Au-thService spravu cookies soubor˚u. Definice modulu services se nacház´ı v souboru

Scripts/services.js a ostatn´ı ˇc´asti jsou pak um´ıstˇeny ve sloˇzce Scripts/Services. ´

Uˇcelem servisu je definovat jednoduché obalové metody pro z´ıskán´ı nebo uloˇzen´ı dat. Metoda pˇrijme objekt, který obsahuje parametry poˇzadavku, a vytvoˇr´ı poˇzadavek podle vzoru. Následnˇe vrát´ı takzvaný objekt promise, který je návrhovým vzorem

(34)

pro asynchronn´ı zpracován´ı událost´ı. Tento objekt m˚uˇze definovat událost vyvola-nou, pokud se podaˇr´ı poˇzadavek dokonˇcit úspˇeˇsnˇe, anebo událost, která se vyvolá pˇri neúspˇechu.

Ukázka takovéto metody je vidˇet ve výpisu kódu 3.8. Metoda definuje klasický HTTP poˇzadavek, konkrétnˇe metodou POST, cestu poˇzadavku, hlaviˇckové infor-mace a pˇr´ıpadná data, poslaná v obsahu poˇzadavku jako je to specifikováno v me-todˇe POST. Obdobnˇe se daj´ı vyuˇz´ıt i jiné druhy HTTP metod jako GET, PUT, DE-LETE atd. Objekt $http je opˇet servis definovaný frameworkem AngularJS a jeho výsledkem je objektpromise.

1 t h i s. g e t T e l e s c o p e s = f u n c t i o n ( p a g i n a t i o n ) { 2 r e t u r n $ h t t p ({ 3 m e t h o d : " P O S T ", 4 url : C O N S T A N T S . A P I _ P R E F I X + " / t e l e s c o p e s ", 5 h e a d e r s : { ’ Content - T y p e ’: ’ a p p l i c a t i o n / j s o n ’ } , 6 d a t a : p a g i n a t i o n 7 }) . e r r o r (f u n c t i o n ( d a t a ) { 8 c o n s o l e . log ( d a t a ) ; 9 c o n s o l e . log (" T e l e s c o p e S e r v i c e e r r o r ") ; 10 }) ; 11 };

K´od 3.8: Uk´azka metody servisu.

Neúspˇeˇsné dokonˇcen´ı poˇzadavku je obsluhováno centrálnˇe v souboru app.js. M˚uˇze být vˇsak obslouˇzeno na v´ıce m´ıstech. Ale snahou tohoto navrˇzeného ˇreˇsen´ı je obsluha ˇspatné události na jednom m´ıstˇe. Podle pˇr´ıznaku, proˇc doˇslo k neúspˇechu, se vykoná akce. Napˇr´ıklad server m˚uˇze odpovˇedˇet, ˇze je identifikaˇcn´ı token ne-platný a uˇzivatel mus´ı z´ıskat nový, tedy se provede akce odhláˇsen´ı uˇzivatele spoleˇcnˇe s vymazán´ım soubor˚u cookies a zobrazen´ım rozvrˇzen´ı stránky pro pˇrihláˇsen´ı. Nebo v pˇr´ıpadˇe chyby se vyp´ıˇse uˇzivateli, proˇc k chybˇe doˇslo.

´

Uspˇeˇsné volán´ı poˇzadavku pak skonˇc´ı obsluhou v kontroleru a vhodným zpra-cován´ım dat s následnou prezentac´ı výsledk˚u.

3.2 Serverov´

a ˇ

c´

ast RTS2 UI

Repozitáˇr obsahuje projekt vývojového prostˇred´ı Netbeans s pluginem Maven ve sloˇzceProject. Zdrojový kód je pak obsaˇzen ve sloˇzceProject/src. Projekt má nˇekolik závislost´ı na ostatn´ıch knihovnách. Vyuˇz´ıvá se platforma Javy verze 1.8. To je spe-cifikováno v nastaven´ı projektu v kompilaci pomoc´ı zvolen´ı JDK 1.8. Dalˇs´ı závislosti jsou na r˚uzných knihovnách, a to pomoc´ı nástroje Maven. Tyto závislosti jsou spe-cifikovány v souboru Project/pom.xml a jejich seznam je vidˇet v tabulce 3.1.

Serverová ˇcást softwaru je koncipována tak, aby nebylo tˇreba instalovat a kon-figurovat ˇzádné jiné doplˇnky a servery pro funkci. Jediné, co je tˇreba, je databáze PostgreSQL. Staˇc´ı spustit program s dostateˇcným oprávnˇen´ım.

(35)

Knihovna Verze Autor Popis

gson 2.8.0 Google Pro pr´aci s JSON form´atem. httpclient 4.5.2 Apache Pro HTTP klienta.

postgresql 9.4.1212.jre7 PostgreSQL Pro komunikaci s DB.

commons-io 2.5 Apache Pro standardn´ı knihovn´ı funkce. Tabulka 3.1: Seznam z´avislosti na ostatn´ıch knihovn´ach.

3.2.1 Konfigurace serveru

Konfiguraˇcn´ı ˇcást serveru je obsaˇzena v souboru rts2ui/Config.java. Je zde moˇzné uzp˚usobit základn´ı nastaven´ı serveru.

Parametr GLOBAL WEB API PATH urˇcuje virtu´aln´ı cestu na serveru k do-taz˚um pro HTTP klienta a jej´ı pˇrednastaven´a hodnota je

”/API“. Pokud napˇr´ıklad bude server poskytovat sluˇzbu na cestˇe

”/getUsers“ pro z´ıskán´ı uˇzivatel˚u, bude m´ıt tato sluˇzba, stejnˇe jako vˇsechny ostatn´ı, obsaˇzenu pˇredponu ve svém smˇerován´ı a to

”/API“, tedy celá cesta bude ”/API/getUser“. Tento princip má výhodu jed-noduchého pˇresunu celé aplikaˇcn´ı vrstvy v pˇr´ıpadˇe nutnosti, která m˚uˇze nastat napˇr´ıklad pokud se bude pˇrekrývat s nˇejakým statickým kontextem nebo jinou kom-ponentou s podobným smˇerován´ım.

Parametr GLOBAL WEB PATH je obdobný parametr, který ale nastavuje vir-tuáln´ı sloˇzku na serveru pro poˇzadavky na statický kontext. Vˇsechny statické texty, ikony, styly atd. jsou dotazovány s touto pˇredponou, aby se opˇet dalo jednoduˇse pˇresmˇerovat v pˇr´ıpadˇe kolize. Pˇrednastavená hodnota tohoto parametru je

”rts2“. Tedy hlavn´ı webov´y interface se zobraz´ı po zad´an´ı poˇzadavku

”http://server/rts2“. Parametr GLOBAL WEB FOLDER PATH urˇcuje, kde se fyzicky na serveru nacház´ı sloˇzka se statickým kontextem webu, tj. klientská ˇcást. Uˇzivatel je pak odst´ınˇen i od informace, kde se tato ˇcást reálnˇe na serveru nacház´ı. Obdobnˇe je spe-cifikován parametr

”GLOBAL WEB INDEX PATH“ pro urˇcen´ı hlavn´ıho souboru klientské ˇcásti. T´ımto souborem se potom odpov´ıdá i na neexistuj´ıc´ı poˇzadavky. Pˇrednastavená hodnota pro hlavn´ı soubor je

”index.html“ a sloˇzka klientsk´e ˇc´asti je ”./Web“.

Dále jsou jeˇstˇe vytaˇzeny parametry pro zmˇenu port˚u. Jak pro klasický HTTP protokol, který vyuˇz´ıvá hlavn´ı server, tak i pro WebSocket server.

Vˇse je nastaveno podle souˇcasného rozloˇzen´ı projektu. Pokud je potˇreba zmˇenit nˇekterou ˇcást, je nutné, aby nastaven´ı odpov´ıdalo. Klient se mus´ı dozvˇedˇet o zmˇenˇe. Napˇr´ıklad pokud se zmˇen´ı cesta pro poˇzadavky, která je nyn´ı

”/API“, mus´ı se na-stavit tato skuteˇcnost i u klienta, a to v souboru Web/Scripts/app.js v ˇc´asti CON-STANTS.

3.2.2 Hlavn´ı logika aplikace

Logika je rozdˇelena na nˇekolik vrstev. Základnˇe jsou to BusinessObjects, DataOb-jects,ValueObjectsaClients. Kaˇzdá vrstva má za úkol konkrétn´ı ˇcinnost, kterou dále

(36)

vysvˇetl´ım. Tento zp˚usob usnadˇnuje orientaci v projektu a dále umoˇzˇnuje snadnˇejˇs´ı nahraditelnost jedné ˇcásti v pˇr´ıpadˇe nutnosti.

ValueObjects

Je nejjednoduˇsˇs´ı vrstvou. Jsou to pamˇet’ové objekty, které pˇrenáˇs´ı data v rámci aplikace. Jsou také známy jako DTO neboli z anglického Data Transfer Object. Objekt je pak z hlavn´ı ˇcásti obrazem databázové tabulky, ale m˚uˇze obsahovat i jiné pˇridané informace. Nemˇel by vˇsak obsahovat ˇzádnou logiku. Zdrojové kódy jsou obsaˇzeny v bal´ıku

”VO“ a maj´ı tuto zkratku obsaˇzenu i v n´azvu objektu, jako napˇr´ıklad

”TelescopeVO“ je objekt uchovávaj´ıc´ı základn´ı informace o teleskopu. Obvykle se tato ˇcást generuje pomoc´ı objektovˇe relaˇcn´ıho databázového nástroje (viz zdroj [7]) jako projekt Hibernate [20]. Ale rozsah databáze projektu nen´ı tak velký a byl radˇeji zvolen zp˚usob roˇcn´ıho napsán´ı.

DataObjects

Tato vrstva objekt˚u zajiˇst’uje ukládán´ı a z´ıskáván´ı objekt˚u z databáze pomoc´ı Value-Objects vrstvy. Vrstva disponuje pˇripojen´ım na databázi. Mapován´ı objekt˚u z vrstvy

ValueObjects zajiˇst’uje mapovac´ımi a pln´ıc´ımi funkcemi. Mapovac´ı funkce (Map) jsou pouˇzity ke konverzi mezi Java objektem a databázovým dotazem. Pln´ıc´ı funkce (Fill) jsou pouˇzity pro z´ıskán´ı dat z dotazu na Java objekt.

Pˇredpokladem této vrstvy je, ˇze data jsou jiˇz oˇsetˇrena na jiné úrovni a vrstva je pouze uloˇz´ı, jak je dostane. Vrstva pˇridává pouze informaci o posledn´ım uloˇzen´ı entity, která se nacház´ı ve sloupci UpdateDate, a dobˇe vzniku entity uloˇzené ve sloupciCreateDate. V pˇr´ıpadˇe neúspˇechu uloˇzen´ı nebo naˇcten´ı vrac´ı vrstva výjimku, nesnaˇz´ı se jakkoliv napravovat situaci nebo nevrac´ı nelogicky null.

Pouˇzit´ı vrstvy by mˇelo být omezeno na nadˇrazenou vrstvu, která se stará o logic-kou ˇcást. Vyuˇzit´ı v jiném projektu nebo rozˇs´ıˇren´ı aplikace je moˇzné, ale mˇelo by být pamatováno na to, ˇze vrstva pouze ukládá a vrac´ı data. Osobnˇe bych zvolil pˇr´ıstup, ˇ

ze by jiná rozˇs´ıˇren´ı aplikace nemˇela moˇznost k vrstvˇe pˇristoupit a mˇela by pouˇz´ıvat nadˇrazenou aplikaˇcn´ı vrstvu i pro ucelen´ı logiky v jednom m´ıstˇe. Tuto skuteˇcnost lze dosáhnout metodou pˇripojen´ı datové vrstvy jako privátn´ı k vrstvˇe logické. Vyuˇzit´ı privátn´ı dostupnosti ale zakáˇze pˇristup k databázi pomoc´ı základn´ıch metod i v pˇr´ıpadˇe vygenerován´ı knihovny. Radˇeji jsem zamezován´ı pˇr´ıstupu nepouˇzil a vrstva je dosaˇzitelná z celé ˇcásti aplikace jako statická knihovna.

Zdrojový kód této vrstvy se pak nacház´ı v bal´ıku

”DO“ a jednotlivé objekty obsahuj´ı zkratku i v názvu. Pˇr´ıkladem objektu z této vrstvy je objekt UserDO, který se stará o práce s daty ohlednˇe databázové tabulky User.

Pro pˇripojen´ı do datab´aze se pouˇz´ıv´a PostgreSQL komponenty ze standardn´ı knihovny.

(37)

Clients

Vrstva Clients zajiˇst’uje komunikaˇcn´ı rozhran´ı mezi serverem RTS2 UI a ostatn´ımi sluˇzbami. V pˇr´ıpadˇe projektu RTS2 UI je to pˇripojen´ı na dalˇs´ı observatoˇre se systémem RTS2. Obecnˇe to pak m˚uˇze být napˇr´ıklad veˇrejnˇe dostupný insolvenˇcn´ı registr ˇCR, ˇci jiné sluˇzby. Komunikace je pak dostupná pˇres standardn´ı protokol.

U vˇetˇsiny tˇechto webových servis˚u se vyuˇz´ıvá mechanismus WSDL, který jed-noduˇse zajist´ı klientské ˇcásti vygenerován´ı datových typ˚u, objekt˚u a metod pro komunikaci. Projekt RTS2 pouˇz´ıvá HTTP protokol pro poskytován´ı a z´ıskáván´ı dat a z toho se nedá jednoduˇse vygenerovat klientský kód. Klientský kód pro komuni-kaci s RTS2 observatoˇr´ı byl realizován ruˇcn´ım pˇrepsán´ım, a to konkrétnˇe v souboru

client/RTS2Client.java. ´

Uˇcelem klientského objektu je poskytnut´ı standardn´ıch metod pro volán´ı sluˇzby. Objekt pak následnˇe podle poˇzadovaných informac´ı zformuluje dotaz podle proto-kolu HTTP a dokumentace [1] a vrát´ı odpovˇed’. Vˇsechny realizované metody funguj´ı synchronn´ım pˇr´ıstupem. Aby se nemusel implementovat protokol HTTP pro komu-nikaci, byla vyuˇzita knihovna httpclient od Apache (viz zdroj [19]).

BusinessObjects

Vstupn´ı bod logické ˇcásti aplikace je vrstvaBusinessObjects. Vrstvu lze pak pˇripojit k jednotlivým úkon˚um uˇzivatele, at’ uˇz z grafického rozhran´ı nebo HTTP poˇzadavku.

´

Uˇcelem této vrstvy je pˇrevzet´ı údaj˚u a následného logického zpracován´ı sloˇzeného tˇreba i z nˇekolika menˇs´ıch úkon˚u z niˇzˇs´ıch vrstev. K realizaci úkon˚u m˚uˇze vrstva vyuˇz´ıt databázovou vrstvuDataObjects neboClients za pomoc´ı vrstvy hodnotových objekt˚uValueObjects.

Vrstva by mˇela oˇsetˇrovat výjimky na úrovni vrácen´ı zmˇen, pokud nˇeco nefun-guje, jak má. Pˇr´ıpadnˇe nahlás´ı stav, ve kterém byla ˇcinnost neoˇcekávanˇe ukonˇcena. Výjimky pak pˇredává vyˇsˇs´ım vrstvám pro prezentaci uˇzivateli a pˇr´ıpadný záznam pro opravu chyb. Zdrojový kód vrstvy se nacházi v bal´ıku

”BO“ a objekty obsahuj´ı v n´azvu stejnou zkratku.

Pˇr´ıkladem objektu vrstvy je ImageBO. Tento objekt se stará o práci z obrázky a je na nˇem vidˇet vyuˇzit´ı logické vrstvy. Pˇri poˇzadavku od uˇzivatele na konkrétn´ı obrázek se provede nejprve dotaz do databáze RTS2 UI. Podle výsledku se provede dalˇs´ı akce. Pokud obrázek jiˇz v databázi existuje, pˇredá se uˇzivateli bez nutnosti kontaktovat RTS2 observatoˇr. Pokud obrázek nen´ı v databázi jeˇstˇe obsaˇzen, poˇzádá se o nˇej u observatoˇre. Data novˇe z´ıskaného obrázku se pak ukládaj´ı do RTS2 UI databáze pro budouc´ı poˇzadavky a pˇredaj´ı se uˇzivateli.

3.2.3 HTTP rozhran´ı serverov´

e ˇ

c´

asti

Protoˇze je aplikace webová a byla zvolena architektura SPA + BackEnd, nebude serverová aplikace pˇripojena na grafické rozhran´ı pˇr´ımo, ale pomoc´ı definovaných metod HTTP protokolu. Server je jednoduchý, vyuˇz´ıvá pouze objektu ze standardn´ı knihovny Javy. Konkrétnˇe se jedná o HttpServer.

(38)

Hlavn´ı tˇr´ıda, která ˇr´ıd´ı a inicializuje serverovou ˇcást, se nazývá MainServer

a nacház´ı se v bal´ıku webcontroller. Je sloˇzena z HTTP a WebSocket serveru. Sa-motná tˇr´ıda MainServer provád´ı inicializaci a nezbytné úkony pro spuˇstˇen´ı ˇcást´ı serveru.

HTTP server

HTTP server je ˇcást kódu, která vyuˇz´ıvá objekt HttpServer. Ten je definován jako seznam obsluh událost´ı na jednotlivá volán´ı. Kaˇzdá obsluha je pak samostatnˇe obsaˇzena v objektuController, který implementuje rozhran´ıHttpHandler.

Rozhran´ıHttpHandler obsahuje metodu handle(), kterou je nutno nadefinovat spoleˇcnˇe s cestou poˇzadavku. ObjektController pak pˇrepisuje tuto metoduhandle()

na koneˇcnou (final), kv˚uli zapouzdˇren´ı chytán´ı výjimek, které neˇcekanˇe nastanou. ObjektController umoˇzˇnuje nadefinovat obsluhu poˇzadavku v metodˇeinerHandle(), kterou internˇe volá metoda rozhran´ıhandle(). Tento mechanismus je zvolen z d˚uvodu stability serveru a definice záznamu chyb na jednom m´ıstˇe. Pˇrepsán´ı metody objektu

Controller je vidˇet ve v´ypisu k´odu 3.9.

1 @ O v e r r i d e 2 p u b l i c f i n a l v o i d h a n d l e ( H t t p E x c h a n g e he ) t h r o w s I O E x c e p t i o n { 3 try { 4 i n e r H a n d l e ( he ) ; 5 } c a t c h ( E x c e p t i o n ex ) { 6 // log ... 7 } 8 }

K´od 3.9: Zapouzdˇren´ı obsluhy HTTP ˇz´adosti.

Pro definice jednotlivých obsluh události jsem pak zvolil objekty, které pouze vyrob´ı objekt typuController, a jsou to objekty obsaˇzené v bal´ıku webcontroller.con-trollers. Jejich struktura je volná, ale snahou je, aby spoleˇcné téma, jako je napˇr´ıklad uloˇzen´ı nebo naˇcten´ı stejného typu objektu, bylo obsaˇzeno v jednom souboru. Pˇr´ı-kladem je spoleˇcná definice obsluh událost´ı pro databázový objekt uˇzivatele, která je definována v souboru UserController. Obsahuje obsluhu pro poˇzadavek k dostán´ı dat vˇsech uˇzivatel˚u

”/getUsers“, jednoho uˇzivatel ”/getUser“ a uloˇzen´ı dat uˇzivatele ”/saveUser“. Definice obsluhy pro uloˇzen´ı uˇzivatele je vidˇet ve v´ypisu k´odu 3.10.

1 p r i v a t e C o n t r o l l e r S a v e U s e r C t r l () { 2 r e t u r n new C o n t r o l l e r (" / s a v e U s e r ", t r u e) { 3 @ O v e r r i d e 4 p u b l i c v o i d i n e r H a n d l e ( H t t p E x c h a n g e t ) t h r o w s E x c e p t i o n { 5 if( G L O B A L _ D E B U G ) 6 S y s t e m . out . p r i n t l n (" S a v e U s e r C t r l : ") ; 7 8 U s e r V O u s e r F r o m J S O N = ( U s e r V O ) G e t O b j e c t F r o m B o d y ( t . g e t R e q u e s t B o d y () , U s e r V O .c l a s s) ; 9 10 U s e r V O u s e r = ( U s e r V O ) t . g e t A t t r i b u t e (" u s e r ") ; 36

(39)

Kapitola 3 - Popis zvolen´eho ˇreˇsen´ı 11 12 U s e r B O . U p d a t e U s e r ( u s e r F r o m J S O N ) ; 13 14 C o n t r o l l e r . S e n d G o o d R e s p o n s e (true, t ) ; 15 } 16 }; 17 }

K´od 3.10: Metoda pro obsluhu poˇzadavku na uloˇzen´ı uˇzivatele.

Vˇsechny poˇzadavky na server jsou realizovány pomoc´ı HTTP metody POST. V tˇele HTTP poˇzadavku je obsaˇzen JSON objekt, který obsahuje potˇrebné data pro realizaci poˇzadavku na stranˇe serveru. Data z formátu JSON jsou pˇrevedena na klasický objekt pomoc´ı knihovny gson. To je zapouzdˇreno do metody GetOb-jectFromBody(), kde je pˇrevod definován.

Obsluha tedy naˇcte data, pokus´ı se provést poˇzadovaný úkon, a pokud bylo vˇse ´

uspˇeˇsné, vrát´ı kladnou odpovˇed’. Odpovˇed’ obsahuje opˇet data ve formátu JSON a o konverzi z Java objektu do JSON formátu se také stará knihovna gson, konkrétnˇe v metodˇe SendGoodResponse().

Pokud poˇzadavek nen´ı z nˇejakého d˚uvodu úspˇeˇsnˇe zpracován, jsou definované standardn´ı odpovˇedi pˇr´ımo jako metody obsluhy, na které patˇriˇcnˇe reaguje klientská strana. Napˇr´ıklad pˇri zavolán´ı metody NotLoggedIn() z objektu Controller, má kli-entská strana definováno v souboru Scripts/app.js, ˇze se mus´ı odhlásit a smazat soubory cookies, protoˇze uˇzivatel nen´ı pˇrihláˇsen nebo nemá platný token pro iden-tifikaci.

Z objektu Controller se tvoˇr´ı objekt HttpContext, kter´y je podobjekt objektu

HttpServer. HttpContext m˚uˇze m´ıt definovaný ˇretˇez obsluh poˇzadavku, který je provázaný a následuje v ˇradˇe za sebou. Jakýkoliv ˇclánek v ˇretˇezu m˚uˇze pˇreruˇsit vykonáván´ı poˇzadavku a vrátit chybu nebo odpovˇed’. Tento ˇretˇez vyuˇz´ıvám pro z´ıskán´ı dat o uˇzivateli. Je definován filtr, který se pˇredˇrad´ı pˇred obsluhy, které to vyˇzaduj´ı. Název objektu obsahuj´ıc´ı filtrovac´ı metodu je TokenFilter a je obsaˇzen v bal´ıku webcontroller.filter. Hlavn´ı metodu je moˇzné vidˇet ve výpisu kódu 3.11.

1 @ O v e r r i d e 2 p u b l i c v o i d d o F i l t e r ( H t t p E x c h a n g e he , C h a i n c h a i n ) { 3 try { 4 // ... 5 if(!( h e a d e r s . c o n t a i n s K e y (" T o k e n ") && h e a d e r s . c o n t a i n s K e y (" U s e r N a m e ") ) ) { 6 C o n t r o l l e r . T o k e n U n p a r s a b l e (" No t o k e n i n f o in h e a d e r . ", he ) ; 7 r e t u r n; 8 } 9 S t r i n g t o k e n = h e a d e r s . get (" T o k e n ") . get (0) ; 10 S t r i n g u s e r N a m e = h e a d e r s . get (" U s e r N a m e ") . get (0) ; 11 U s e r V O u s e r = U s e r B O . I s L o g g e d I n ( token , u s e r N a m e ) ; 12 13 if( u s e r == n u l l) { 14 C o n t r o l l e r . N o t L o g g e d I n (" T o k e n e x p i r e d . ", he ) ; 15 r e t u r n;

(40)

Kapitola 3 - Popis zvolen´eho ˇreˇsen´ı 16 } e l s e { 17 he . s e t A t t r i b u t e ( U S E R _ O B J E C T _ S T R I N G , u s e r ) ; 18 } 19 c h a i n . d o F i l t e r ( he ) ; 20 } c a t c h ( E x c e p t i o n ex ) { 21 // ... 22 // r e t u r n s e r v e r f a i l e d 23 } 24 } 25 }

K´od 3.11: Hlavn´ı metoda filtru pro tokenovou autorizaci poˇzadavku.

´

Uˇcelem tohoto filtru je pˇreˇc´ıst hlaviˇcku poˇzadavku, pod´ıvat se jestli obsahuje token ve správné podobnˇe. Pokud neobsahuje, rovnou odpov´ıdá klientovi chybou, a ten následnˇe smaˇze cookies a zobraz´ı uˇzivateli moˇznost se znovu pˇrihlásit. Pokud obsahuje poˇzadavek token, provede se poté dotaz do databáze a v pˇr´ıpadˇe platnosti tokenu se jeho platnost opˇet prodlouˇz´ı o nˇejaký konstantn´ı ˇcas (konkrétnˇe 8 hodin). Pokud token jiˇz nen´ı platný, neumoˇzn´ı se uˇzivateli pˇristup k dalˇs´ı ˇcásti poˇzadavku a odpov´ı se klientovi tak, aby uˇzivatele identifikoval znovu.

V pˇr´ıpadˇe platného tokenu se vytaˇzený záznam dat uˇzivatele z databáze rovnou pouˇzije jako atribut v objektuHttpExchange, který si jednotlivé obsluhy mezi sebou vzájemnˇe pˇredávaj´ı a mohou do nˇej ukládat jiné podobjekty. Konkrétnˇe se tento objekt uloˇz´ı pod názvem

”user“ a ostatn´ı obsluhy poˇzadavk˚u jej mohou pˇreˇc´ıst bez volán´ı z databáze. Obsluhy za tokenovým filtrem mohou pˇredpokládat, ˇze je uˇzivatel ovˇeˇren, a pracovat se z´ıskanými daty bez nutnosti znovuovˇeˇren´ı. T´ımto zp˚usobem je realizováno ovˇeˇren´ı uˇzivatele na stranˇe HTTP serveru.

HTTP server je obsluhován v´ıcevláknovˇe. Konkrétnˇe byl zvolen pˇr´ıstup vytvoˇren´ı poˇctu vláken, které se staraj´ı o obsluhu klienta, podle aktuáln´ı potˇreby. Pokud je vlákno ukonˇceno, z˚ustává po dobu jedné minuty v pamˇeti. Pokud do té doby nen´ı vyuˇzito, tak zaniká, aby uvolnilo systémové prostˇredky.

WebSocket server

Druhou serverovou ˇcásti je WebSocket server. Ten je implementován základnˇe podle dokumentace ve zdroji [8]. Základem je klasická soketová komunikace, které eviduje jednotlivé klienty. Kaˇzdý klient nejprve naváˇze komunikaci pomoc´ı HTTP proto-kolu a poˇzádá v nˇem o zmˇenu komunikace na základn´ı soketovou komunikaci. Tato zmˇena tzv.handshake je implementován podle dokumentace a vyzkouˇsen v souboru

Web/websocket.html, kter´y obsahuje JavaScriptov´eho klienta.

Výhoda WebSoketové komunikace oproti HTTP komunikaci je moˇznost kontak-tovat klienta pˇr´ımo ze serveru. Server pak nemus´ı být pˇretˇeˇzován poˇzadavky, at’ uˇz periodickými nebo pozastavenými, které daj´ı odpovˇed’ v dobˇe zmˇeny.

(41)

Obrázek 3.2: Schéma databáze RTS2 UI.

3.3 Datab´

aze RTS2 UI

Databáze projektu RTS2 UI je navrˇzena, aby zbyteˇcnˇe netvoˇrila duplicity. Pokud je moˇzné z´ıskat informaci z observatoˇre, z´ıská se z observatoˇre. Ukládaj´ı se pouze data, která souvis´ı pˇr´ımo s aplikac´ı.

Potˇreba je uloˇzit informace o uˇzivatel´ıch, kteˇr´ı budou systém vyuˇz´ıvat, jejich identifikace a pˇr´ıpadnˇe dalˇs´ı údaje. A kaˇzdý uˇzivatel bude m´ıt evidovanou roli, pod kterou v systému vystupuje.

Dále se mus´ı uloˇzit informace o observatoˇr´ıch, které systém RTS2 UI m˚uˇze vyuˇz´ıt. Je potˇreba uloˇzit jejich veˇrejnˇe dostupná internetová adresa a údaje pro pˇrihláˇsen´ı.

´

Udaje pro pˇrihláˇsen´ı se ukládaj´ı pouze v textové podobˇe, protoˇze je potˇreba znát heslo. A dalˇs´ı atributy, jako napˇr´ıklad veˇrejné ˇcasy observatoˇre nebo pojmenován´ı.

Protoˇze oprávnˇen´ı scientist má m´ıt moˇznost pˇristupovat pouze k pˇridˇeleným observatoˇr´ım, je tato informace uchována v databázi RTS2 UI. Informace se ukládá v jednoduché tabulce, které nahrazuje vazbu N:M a skládá se pouze z identifikace uˇzivatele a teleskopu.

Data obrázk˚u se uchovávaj´ı v databázi RTS2 UI. Je to z d˚uvodu odlehˇcen´ı toku dat mezi observatoˇr´ı a serverem RTS2 UI. Pro jednoduchost je uloˇzen formát JPEG i FITS. Formát JPEG by se dal z´ıskat z FITS formátu, ale systém zat´ım nepracuje s knihovnou, která by tuto konverzi umoˇznila.

Datab´aze je navrˇzena s ohledem na relaˇcn´ı vazby. Software nemus´ı nutnˇe hl´ıdat, jestli je integrita dat v poˇr´adku.

(42)