České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Licenční server Bc. Ondřej Tománek
Vedoucí práce: Ing. Stanislav Flígl, PhD.
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 9. května 2012
iv
v
Poděkování Děkuji své rodině za trpělivost v uplynulém náročném roce. Děkuji pracovníkům společnosti ŠKODA ELECTRIC a.s., jmenovitě Ing. Stanislavu Flíglovi, Ph.D. a Bc. Jiřímu Svatošovi za pomoc při snaze pochopit problémy domény dopravního strojírenství. Dále děkuji Ing. Tomáši Kadlecovi, Ing. Petru Aubrechtovi, PhD. a Ing. Zdeňku Troníčkovi, PhD. za cenné technologické rady.
vi
vii
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
V Pardubicích dne 9. 5. 2012
.............................................................
viii
Abstract The objective of this diploma project is to analyze SKODA ELECTRIC’s diagnostic software usage system. The main goal of this project is to implement proposed solution in the form of license server, that solves problems found in the old system. The server sits in the middle of newly suggested distributed system. License server is composed of many components and the thesis describes them through all of the software lifecycle phases. In the end the server is to be tested in configured testing enviroment to prove the concept.
Abstrakt Úkolem této diplomové práce je analyzovat současný způsob používání diagnostického software společnosti ŠKODA ELECTRIC. Hlavním cílem tohoto projektu je implementovat navrhnuté řešení ve formě licenčního serveru, který řeší nalezené problémy starého systému. Server je v ústředí nově navrženého distribuovaného systému. Licenční server se skládá z mnoha komponent a práce je popisuje v průběhu všech fází životního cyklu softwaru. Na závěr bude server otestován v nakonfigurovaném testovacím prostředí pro ověření funkčnosti.
ix
x
Obsah 1 Úvod
1
2 Popis problému, specifikace cíle 2.1 Stávající řešení . . . . . . . . . . . . 2.1.1 Vývoj regulačních algoritmů . 2.1.2 Distribuce uložených záznamů 2.1.3 Problém . . . . . . . . . . . . 2.2 Vize . . . . . . . . . . . . . . . . . . 2.3 Požavavky na server . . . . . . . . . 2.4 Cíl práce . . . . . . . . . . . . . . . . 2.5 Definice používaných pojmů . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
5 5 7 8 9 10 11 11 11
3 Analýza 13 3.1 Webová služba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Správa uživatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Návrh řešení 4.1 Systémová architektura . . . . . . . . . . . 4.1.1 Diagnostická aplikace . . . . . . . . . 4.1.2 Informační systémy . . . . . . . . . . 4.1.3 Řídicí jednotky . . . . . . . . . . . . 4.2 Serverová architektura . . . . . . . . . . . . 4.2.1 Řešení architektonických požadavků 4.2.2 Vzory . . . . . . . . . . . . . . . . . 4.2.2.1 Model, View, Controller . . 4.2.2.2 High Cohesion . . . . . . . 4.2.2.3 View Manager . . . . . . . 4.2.2.4 Concrete Table Inheritance 4.2.2.5 Proxy . . . . . . . . . . . . 4.2.3 Systém balíčků . . . . . . . . . . . . 4.3 Datový model . . . . . . . . . . . . . . . . . 4.3.1 Speciální entity . . . . . . . . . . . . 4.3.2 Licence a projekty . . . . . . . . . . 4.3.3 Role a skupiny . . . . . . . . . . . . 4.3.4 Akce a parametry . . . . . . . . . . . xi
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
19 19 19 20 20 21 21 23 24 24 25 25 26 27 28 29 29 30 32
xii
OBSAH
4.3.5
Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5 Implementace 5.1 Webové rozhraní . . . . . . . . . . . . 5.1.1 Technologie . . . . . . . . . . . 5.1.2 Organizace tříd . . . . . . . . . 5.1.3 Organizace hlavní obrazovky . 5.1.4 Správa uživatelů . . . . . . . . 5.2 Business logika . . . . . . . . . . . . . 5.2.1 Přístupové body . . . . . . . . 5.2.1.1 LDAPAccessPoint . . 5.2.1.2 DBAccessPoint . . . . 5.2.1.3 BaanSQLAccessPoint 5.2.2 Pomocné třídy . . . . . . . . . 5.3 Webová služba . . . . . . . . . . . . . 5.3.1 Úkoly služby . . . . . . . . . . 5.3.2 Použité technologie . . . . . . . 5.3.3 Rozhraní klientské knihovny . . 5.3.4 Řešení problémů . . . . . . . . 5.4 Bezpečnost . . . . . . . . . . . . . . . 5.4.1 Generování otisků . . . . . . . 5.4.2 Šifrování . . . . . . . . . . . . . 5.4.3 AAA . . . . . . . . . . . . . . . 5.4.4 Ochrana před útoky . . . . . . 5.4.5 Aplikace bezpečnosti . . . . . . 5.4.5.1 Transfer hesel . . . . . 5.4.5.2 Transfer licencí . . . . 6 Nasazení 6.1 Licenční server . . 6.2 Klienti . . . . . . . 6.3 Databázové stroje . 6.4 LDAP server . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
7 Testování 7.1 Jednotkové testy klientské knihovny 7.1.1 Technologie . . . . . . . . . . 7.1.2 Výsledky . . . . . . . . . . . 7.2 Testování webového rozhraní . . . . 7.2.1 Technologie . . . . . . . . . . 7.2.2 Pořizování dat . . . . . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
35 35 35 36 37 38 40 40 40 41 43 44 45 45 46 48 48 51 51 52 54 56 58 58 58
. . . .
61 62 63 64 65
. . . . . .
67 67 67 68 69 70 70
8 Závěr 73 8.1 Do budoucna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Literatura
75
OBSAH
xiii
A Seznam použitých zkratek
77
B Popis použitých knihoven
81
C Externí související systémy
83
D Konfigurace aplikace a serveru 85 D.1 Deployment aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 D.2 Nastavení služeb webového kontejneru . . . . . . . . . . . . . . . . . . . . . . 85 D.3 Konfigurace aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 E Obsah přiloženého CD
89
xiv
OBSAH
Seznam obrázků 1.1 1.2 1.3
Koněspřežná tramvaj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tramvaj značky ŠKODA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logo společnosti ŠKODA . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 2.2 2.3
Případy užití pro scénář vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Případy užití pro scénář distribuce . . . . . . . . . . . . . . . . . . . . . . . . 8 Nový distribuovaný systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 3.2 3.3 3.4
Fragment modelu požadavků na webovou službu . . . . Případy užití webové služby . . . . . . . . . . . . . . . . Fragment modelu požadavků na modul správy uživatelů Případy užití modulu správy uživatelů . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
14 15 16 17
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12
Řídící jednotka . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram komponent vzoru MVC v kontextu licenčního serveru Třída CryptoUtil . . . . . . . . . . . . . . . . . . . . . . . . . . Třída ViewManager . . . . . . . . . . . . . . . . . . . . . . . . Vzor Concrete Table Inheritance v kontextu licenčního serveru . Rozhraní a implementace knihovny klientské aplikace . . . . . . Fragment hierarchie balíčků . . . . . . . . . . . . . . . . . . . . Speciální entity . . . . . . . . . . . . . . . . . . . . . . . . . . . Licence a projekty . . . . . . . . . . . . . . . . . . . . . . . . . Role a skupiny . . . . . . . . . . . . . . . . . . . . . . . . . . . Akce a parametry . . . . . . . . . . . . . . . . . . . . . . . . . . Stavový diagram uživatelského účtu . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
21 24 25 26 27 27 28 29 30 31 32 34
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10
Architektura frameworku Vaadin . . . . . . . . . . Přihlašovací obrazovka . . . . . . . . . . . . . . . . Hierarchie tříd uživatelského rozhraní . . . . . . . . Uvítací panel . . . . . . . . . . . . . . . . . . . . . Formulář pro založení nového uživatele . . . . . . . Tabulka s databází uživatelů . . . . . . . . . . . . . Třída LDAPAccessPoint . . . . . . . . . . . . . . . Fragment třídy DBAccessPoint . . . . . . . . . . . Třída BaanSQLAccessPoint . . . . . . . . . . . . . Diagram komponent webové služby LicenseService
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
36 38 39 40 41 42 43 43 44 45
xv
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . .
. . . . . . . . . .
. . . .
. . . . . . . . . .
. . . .
. . . . . . . . . .
. . . . . . . . . .
1 2 3
xvi
SEZNAM OBRÁZKŮ
5.11 5.12 5.13 5.14 5.15 5.16 5.17 5.18
Příklad komunikace . . . . . . . . . . . . . . . . WSDL webové služby licenčního serveru . . . . Rozhraní knihovny klienta webové služby . . . Hashovací a šifrovací funkce licenčního serveru . Proces ověřování validity klíčů aplikací DisMon Proces přihlášení uživatele . . . . . . . . . . . . Offline přihlášení uživatele do DisMonu . . . . . Ověření digitálního podpisu licence . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
46 49 50 53 54 55 59 60
6.1 6.2 6.3
Plně nasazený licenční server . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Detail licenčního serveru v kontextu nasazení . . . . . . . . . . . . . . . . . . 63 Klienti licenčního serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
7.1 7.2
Jednotkové testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Pořizování vstupních dat pro testování . . . . . . . . . . . . . . . . . . . . . . 71
Seznam tabulek 4.1 4.2
Speciální atributy v datovém modelu . . . . . . . . . . . . . . . . . . . . . . . 33 Stavy uživatelského účtu vzhledem ke skupině ClassUserGroup . . . . . . . . 33
5.1 5.2 5.3 5.4 5.5 5.6 5.7
Balíčky webového rozhraní . . . . . . . . . . . . . Srovnání JPA frameworků . . . . . . . . . . . . . Role webové služby . . . . . . . . . . . . . . . . . Srovnání RPC technologií a webových služeb . . Popis výjímek . . . . . . . . . . . . . . . . . . . . Porovnání hashovacích funkcí SHA1 a SHA512 . Porovnání asymetrické a symetrické kryptografie
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
37 44 45 47 51 52 53
E.1 Popis souborů a adresářů na přiloženém CD . . . . . . . . . . . . . . . . . . . 91
xvii
xviii
SEZNAM TABULEK
Kapitola 1
Úvod Doprava v průběhu existence lidstva hraje stále více významnou roli. Zpočátku to byla především nákladní doprava, která měla za úkol přepravovat malé objemy zboží, které již nebylo možné nebo pohodlné nést. Jmenujme například sedláka s jeho sklizní nebo obchodníka s jeho zbožím cestou na trh. Tento model však nepřetrval věčně. Vesnice se pomalu začaly rozrůstat do měst a vyvrcholením tohoto procesu byla průmyslová revoluce, následovaná vznikem velkoměst. Protože s růstem počtu obyvatel rostou i vzdálenosti pro přesun do práce, za zábavou a domů, začala nabývat na významu také doprava osobní. Důsledky průmyslové revoluce se projevily na konci 19. století. Osobní dopravě tehdy dominovaly tramvaje, konkrétně tramvaj koněspřežná [9] a následně tramvaj parní. Roku 1879 se na výstavě v Berlíně poprvé představila tramvaj elektrická. Ta se následně stala hlavním dopravním prostředkem osobní dopravy na dlouhou dobu. Již roku 1885 byl ale představen první osobní vůz se spalovacím motorem a především pro západní země začala éra automobilismu.
Obrázek 1.1: Koněspřežná tramvaj
1
2
KAPITOLA 1. ÚVOD
Západ postupně přecházel z městské hromadné dopravy1 jako těžiště osobní dopravy na individuální automobilovou dopravu. To, společně s přesunem západních technologií na východ, bylo příčinou skutečnosti, že o skoro více než 150 let později můžeme rozlišit dva modely osobní dopravy v jednotlivých zemích - model rozvinutých zemí a model rozvojových zemí. Obecně ve městech tvoří osobní doprava 80-90% všech dopravních prostředků. V rozvinutých zemích je vyšší životní úroveň a vyšší míra automobilizace. Individuální automobilová doprava zde představuje 70-80% osobní dopravy. Pro MHD tedy zbývá 20-30%. Naopak rozvojové země mají podíl přepravní kapacity MHD opačně vysoký, pohybuje se mezi 60-70%. Na individuální automobilovou dopravu tudíž zbývá pouhých 30-40%. Model rozvinutých zemí ale v dnešní době naráží na problémy a výhody individuální automobilové dopravy se postupně vytrácí. Mluvíme například o nedostatku parkovacích míst, o dopravních zácpách a o ekologii. Rozvinuté země se proto v dnešní době snaží vší silou o návrat k původnímu modelu, znovuvybudování sítě MHD tam, kde byla byla zrušena, další rozšíření existujících sítí a celkově tak o plné využití výhod MHD. Mezi ty řadíme například relativně nízkou míru hluku, nižší energetickou náročnost, bezpečnost a dobrou dostupnost [13]. Pomocí zdůrazňování právě těchto výhod lidem se snaží vlády rozvinutých států motivovat k návratu k využívání MHD. “Podíl přepravní kapacity MHD v českých městech není však výsledkem přirozeného vývoje. Její dominantní postavení na úkor dopravy individuální bylo dáno tím, že občané neměli jinou volbu, neboť automobil nevlastnilo dříve zdaleka tolik lidí jako v dnešní době.”[6] Navíc Česká republika byla vždy zemí průmyslově vyspělou a MHD zde má dlouhodobou tradici. Důvody pro využívání MHD jsou u nás tedy trochu odlišnější než v jiných zemích. Aktuálními trendy v MHD jak v rozvojových, tak v rozvinutých zemích, jsou například snahy o integrování dopravy a zkvalitňování služeb po stránce komfortu. MHD je tedy hojně využívána lidmi po celé Zemi a v dohledné době tomu nebude jinak.
Obrázek 1.2: Tramvaj značky ŠKODA
1
zkráceně MHD
3 Tramvaje, stejně jako ostatní prostředky MHD, jsou ve velké míře vytěžovány a to, společně s regulérními intervaly údržby po určitém počtu najetých kilometrů, je příčinou občasné nutnosti servisního zásahu. V dnešní době, kdy v těchto dopravních prostředcích jsou umístěny regulátory a většina funkcí dopravního prostředku je ovládána elektronikou, si pod takovým servisním zásahem musíme představit mnohem více, než pouhou diagnostiku chyby a její odstranění. Servisní technici v dnešní době mají širokou škálu možností nastavování parametrů, podle kterých se dopravní prostředek bude při provozu chovat. Dnes už tedy výrobci dopravních prostředků musí pro své servisy vyvíjet komplexní desktopové klientské aplikace, které umožňují snadnou orientaci ve velkém množství použitelných funkcí a možností dopravního prostředku. Taková aplikace je tedy nutným vybavením každého servisního technika, které je již dlouhou dobu považováno za samozřejmé. Společnost ŠKODA ELECTRIC je předním světovým výrobcem elektrických pohonů a trakčních motorů pro trolejbusy, tramvaje, lokomotivy, příměstské vlakové jednotky, metra a důlní vozidla. Navazuje na dlouholetou tradici elektrotechnické výroby Škodových závodů v Plzni, která byla zahájena v roce 1901 v Elektrotechnickém závodě [11]. Prvopočátky samotné stojírenské výroby v Plzni se však datují do roku 1859, kdy zde hrabě ValdštejnVartenberk založil pobočku své slévárny a strojírny. Továrnu o 10 let později odkoupil hlavní inženýr Ing. Emil Škoda.
Obrázek 1.3: Logo společnosti ŠKODA
4
KAPITOLA 1. ÚVOD
Kapitola 2
Popis problému, specifikace cíle 2.1
Stávající řešení
Společnost ŠKODA ELECTRIC soustřeďí vývoj software ve městech Plzeň a Praha. V Plzni se vyvíjí především systémový software a dále řídicí aplikace pro dopravní prostředky MHD. V Praze probíhá především vývoj řídicích aplikací pro měniče velkého výkonu1 . Společnost má dlouhodobý zájem na spolupráci s univerzitami. Součástí tohoto dlouhodobého záměru je i podpora rozvoje aplikace DisMon. DisMon je interním softwarovým produktem společnosti ŠKODA ELECTRIC. Jde původně o jeden z mnoha interních pomocných nástrojů pro podporu vývoje embedded aplikací (ladící nástroj), který navazuje na řadu svých předchůdců (DisShow, Monitor, . . . ). Rozšířením nasazení aplikace za hranice oddělení vývoje software její používání postupně nenápadně nabývalo na větším a větším významu a dostalo tak zcela novou dimenzi. DisMon se vedle stále probíhající nezbytné údržby původního řešení aktuálně nachází také ve fázi reimplementace, kde jde především o převod jádra i uživatelského rozhraní z aplikace psané v jazyce C/C++ do platformy Netbeans RCP s využitím knihovny Swing a doplnění některých nových systémových návazností (rozhraní). Současná softwarová podpora pro diagnostiku se skládá z desktopové aplikace DisMon, systémových knihoven a dat pro celou škálu regulátorů SELČ. Stávající diagnostickou aplikaci využívají vývojáři k ladění parametrů aplikace nahrané v řídící jednotce. Diagnostická aplikace je rovněž použita ve zkušebnách pro servisní ladění povolených parametrů aplikace a taktéž jí využívají koncoví zákazníci ve svých servisech a tato aplikace je typicky součástí dodávky elektrovýzbroje. Samotná diagnostická aplikace se skládá z několika funkčních celků: • Zobrazování aktuálních hodnot vybraných veličin • Zobrazování archivu událostí • Zobrazování příloh veličiny zaznamenané události • Zobrazování příloh průběhů veličin zaznamenané události • Nahrání nové aplikace do řídící jednotky 1
až do cca 10 MW
5
6
KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
• Okno pro změnu vybraných proměnných v řídící jednotce • Okno pro změnu vybraných proměnných v řídící jednotce
2.1. STÁVAJÍCÍ ŘEŠENÍ
7
Existuje mnoho různých způsobů využívání diagnostického software pracovníky SELČ a jejími zákazníky. Popíšeme dva z těch častějších scénářů.
2.1.1
Vývoj regulačních algoritmů
Obrázek 2.1: Případy užití pro scénář vývoje Obrázek 2.1 ukazuje případy užití při scénáři, kdy technik-vývojář vytváří software, obsahující regulační algoritmy. Při vývoji je třeba software průběžně testovat a získávat zpětnou vazbu od hardwarového regulátoru. V tu chvíli technik využívá aplikaci DisMon ke změnám proměnných parametrů regulátoru nebo k nahrání vytvořené aplikace do regulátoru. Zpětnou vazbou je potom vyčtení hodnot proměnných a parametrů regulátoru, zobrazování grafů nebo stahování záznamů.
8
2.1.2
KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
Distribuce uložených záznamů
Obrázek 2.2: Případy užití pro scénář distribuce Obrázek 2.2 ukazuje případy užití při scénáři, kdy v regulátoru došlo k chybě. Uložené záznamy v regulátoru jsou totiž klíčovou informací pro určení příčiny vzniklých chyb nebo nestandardního chování regulátorů. Tato data se musí nějakou cestou dostat k vývojáři, který má danou chybu odstranit. Jejich distribuce je řešena různými způsoby, s výjimkou několika typů vozidel, napojených na aplikace DataRail nebo TeleRail, neexistuje předepsaný způsob ukládání záznamů.
2.1. STÁVAJÍCÍ ŘEŠENÍ
2.1.3
9
Problém
Na aplikaci DisMon jsou ovšem kladeny vysoké nároky a aplikace jako taková má mj. mnoho návazností na další systémy. Z těchto faktů plynou problémy: Notifikace2 slouží jako zdroj informací. Je tedy třeba umět posílat zprávy jiným interním aplikacím a znát tím pádem mnoho komunikačních API. ERP systémy ve společnosti slouží především pro ukládání informací o zakázkách, výrobě a zákaznících. Historicky jedním z nejstarších systémů je Baan. Postupem času byly některé funkcionality převedeny do jiných systémů - (SmartTeam, EasyArchive, . . . ), které při své práci využívají pohledy na data, které jsou exportovány ze systému Baan a které do systému Baan vybraná data zároveň exportují. Identifikace komponent dodávaných do dopravních prostředků mnohdy není dostupná. Typicky skříně, do kterých se elektronické řídící karty vkládají, ID postrádají úplně nebo je obtížně čitelné strojově. Zdaleka největším problémem však je bezpečnostní model aplikace. V dnešní době má totiž zákazník právo s regulátorem po získání hesla anonymně a libovolně manipulovat a navíc spolu s dodanou aplikací zákazník aktuálně dostává kompletní historii nastavovaných parametrů předchozích zákazníků. Tento nežádoucí stav plyne ze 2 skutečností: Neexistence vazeb v aplikaci, které by do souvislosti dávaly konkrétního zákazníka a funkcionalitu aplikace. Existuje několik klíčů, které dávají uživateli přístup k funkcionalitám aplikace. Jeden z klíčů ale odemyká kompletní funkcionalitu aplikace a jeho znalost je tedy ekvivalentní vlastnictví plné verze aplikace. Tento model sice znamená minimum práce pro výrobce, ale zároveň představuje bezpečnostní riziko prozrazení klíče, na což nelze reagovat jeho expirací nebo okamžitou změnou. Monolitičnost aplikace je příčinou toho, že se aplikace těžko fragmentuje na modulární celky a proto zákazník v současné době získává jeden velký celek, který v sobě obsahuje i historii nastavení regulátorů, se kterými daný zákazník nemá žádný vztah. I toto lze považovat za bezpečnostní riziko, konkrétně únik dat.
2
alarmy, emailová hlášení
10
KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
2.2
Vize
Původní systém se tedy ukázal býti nevhodným a jako dlouhodobé řešení byl navržen nový, sice stále distribuovaný model fungování aplikace, ale doplněný centrální správou. Jádrem tohoto systému bude licenční server, jehož hlavními úkoly budou bezpečnost aplikace ve smyslu AAA3 a vydávání licencí. Stáhnuté licence navíc budou umožňovat offline práci techniků v terénu. Server jako takový se bude skládat ze 2 hlavních částí - webové aplikace a webové služby: Webová aplikace bude poskytovat webové rozhraní pro komplexnější manipulaci s uživatelskými účty a licencemi. Webová služba bude naslouchat požadavkům klientů - instancím aplikace DisMon. Pod požadavky rozumějme například žádost o autentizaci, stažení licence nebo informaci o dostupnosti komunikačního kanálu4 . Jak webová služba, tak webová aplikace jsou extranetové aplikace společnosti ŠKODA. Licenční server navíc pro svou správnou funkci musí komunikovat s intranetovými aplikacemi a servery, ke kterým by jinak uživatel z extranetu neměl přístup. Model propojení jednotlivých prvků v novém systému ukazuje obrázek 2.3.
Obrázek 2.3: Nový distribuovaný systém
3 4
autentizace, autorizace, účtování (z angl. Authentication, Authorization, Accounting) tzv. keepalive zpráva
2.3. POŽAVAVKY NA SERVER
2.3
11
Požavavky na server
Na licenční server jsou kladeny mnohé požadavky. Architektonické požadavky uvedeme již nyní: • Open source • Nezávislost • Rozšiřitelnost • Modularita • Výkon • Lokalizace • Dokumentace • Bezpečnost
2.4
Cíl práce
Práce pojednává o limitacích současného modelu fungování techniků a diagnostických aplikací ve společnosti ŠKODA ELECTRIC. Starý systém v dnešní době již nemůže dlouhodobě obstát a pro společnost představuje jak bezpečnostní riziko, tak i potenciálně ušlý zisk. Celou situaci a fungování v doméně práce analyzuje. Již předem navržené řešení práce implementuje v podobě nejdůležitější komponenty nového modelu fungování - licenčního serveru. Nový model si obecně bere to kvalitní a časem prověřené z původního modelu. Zároveň přidává nové prvky, které system dělají použitelnějším, bezpečnějším a robustnějším. Server je popsán ve všech etapách vývoje softwarového produktu. Jsou uvedeny požadavky na systém, návrh architektury, implementace všech částí a modulů, zabezpečení, konfigurace, testování a vykrystalizované závěry. Datovému modelu, jako důležité součásti návrhu zdroje dat aplikace, je také věnována celá sekce. Přílohy uvádějí návod k takové konfiguraci serveru, která umožní jeho odzkoušení v testovacím prostředí.
2.5
Definice používaných pojmů
Definice 1 Regulátor (elektronická řídící jednotka) je zařízení pro řízení systémů, například dopravních prostředků. Definice 2 Regulační algoritmus je program, nahrávaný do regulátoru za účelem změny jeho chování. Definice 3 CA je libovolný softwarový produkt, nahrávaný do procesoru řídící jednotky. Definice 4 Skříň je kontejner pro hardware dopravních prostředků.
12
KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Analýza Architektonické požadavky již byly zmíněny. Očekávání zákazníka je ale třeba zachytit i ve formě funkčních požadavků, protože jsou to právě firemní procesy, které licenční server musí podpořit a jejichž softwarové obrazy patří mezi hlavní stimuly investic do nového systému. Pro přehlednost se zaměříme na dvě hlavní funkční oblasti licenčního serveru - webovou službu a správu uživatelů přes webové rozhraní.
3.1
Webová služba
Nepřímo je využívána servisními techniky při používání diagnostické aplikace. Nová generace aplikace DisMon totiž pro svou plnou funkčnost potřebuje TCP/IP konektivitu k serveru, se kterým si následně vyměňuje velké množství nejrůznějších zpráv. Běžný uživatel tedy přítomnost webové služby nepozná, protože aplikace DisMon a knihovna klientské strany webové služby tvoří odstiňující vrstvy. Kdo ale webovou službu vnímá a potřebuje je vývoj aplikace DisMon. Ten je sice od low-level komunikačního API webové služby odstíněn klientskou knihovnou, ale požadavky ve formě volání metod knihovny se stejně většinou promítnou do ekvivalentního volání metod na serveru. Existují výjímky ve chvíli, kdy limitace technologie konkrétní webové služby tvoří nepřekonatelnou překážku1 . Požadavky na aplikaci DisMon tedy mnohdy implikují požadavky na webovou službu licenčního serveru. Požadavky na webovou službu a jejich celkové začlenění do hierarchie požadavků dokládá fragment UML modelu požadavků na obrázku 3.1. Typický scénář případu užití webové služby při zjištění dostupných licencí potom vypadá následovně: 1. Případ užití začíná, když uživatel iniciuje proces stažení licence 2. DisMon přijme od uživatele jeho přihlašovací jméno a heslo 3. INCLUDE (Přihlásit) 4. Server zašle uživateli seznam jeho licencí 5. EXTEND (Stáhnout licenci) 13
14
KAPITOLA 3. ANALÝZA
1. Systém bude poskytovat více rozhraní pro alternativní způsoby využití
1.1. Server bude poskytovat webové rozhraní
1.2. Server bude poskytovat rozhraní webové služby
1.2.1. Služba bude poskytovat informace o dostupných licencích 1.2.2. Služba bude umožňovat stažení konkrétních licencí
1.2.3. Služba bude reagovat na změny stavu klientů
1.2.4. Služba bude poskytovat informace nutné pro uložení otisku uživatelkých hesel
1.2.5. Služba bude poskytovat informace nutné k ověření digitálních podpisů licencí
Obrázek 3.1: Fragment modelu požadavků na webovou službu
Zbytek fragmentu modelu případů užití, do kterého patří i uvedený scénář, uvádí obrázek 3.2. Roli actora zde na sebe bere aplikace DisMon, která uživatelovy požadavky překládá dle svého uvážení do volání webové služby.
3.2
Správa uživatelů
V doméně dopravního strojírenství působí mnoho subjektů na straně nabídky i poptávky. V kontextu licenčního serveru vidíme SELČ na straně nabídky. Na straně poptávky existují různé společnosti a dopravní podniky velkých měst, které SELČ eviduje hierarchií zakázek a kusovníků objednaného zboží. Při přístupu ke sdíleným zdrojům2 jsou však třeba silnější nástoje než prostá statická evidence. Je třeba se na zákazníky dívat nejen z pohledu jejich příslušnosti k zákaznické společnosti, ale i jako na jedince s určitými kompetencemi a právy. Pro účely řízení kontroly jejich akcí nad sdílenými prostředky je navíc mnohdy nutné definovat nějakou analogii aplikačních rolí, které se mnohdy budou lišit od jejich skutečných pracovních pozic a práv v rámci jejich zaměstnavatele. Z toho všeho plyne jasně potřeba existence části aplikace, která se v dnešní době nazývá “Správa uživatelů”. Její nutnost většinou vyplyne napovrch při analýze, protože zákazník si ne vždy uvědomí její nepostradatelnost. Modul správy uživatelů v licenčním serveru tvoří velký koherentní celek, který je navržen a implementován v souladu z vydefinovanými požadavky, jejichž část zobrazuje diagram na 1 2
technologie JAX-WS například neumí přetěžovat metody firemní software a systémy
15
3.2. SPRÁVA UŽIVATELŮ
License Service
Zjistit dostupné licence
Stáhnout licenci «extend»
«include»
Stáhnout veřejný klíč «include»
DisMon
Přihlásit
Stáhnout otisk hesla
«include»
«include»
Odhlásit
Obrázek 3.2: Případy užití webové služby
obrázku 3.3. Návrh samotné struktury skupin, rolí a uživatelů je popsán v sekci 4.3. Typický scénář případu užití modulu při smazání uživatele potom vypadá následovně: 1. Případ užití začíná, když administrátor chce smazat uživatelský účet 2. INCLUDE (Zobrazit seznam uživatelů) 3. Systém zobrazí tabulku s možnými operacemi 4. Uživatel volí a potvrzuje možnost smazání uživatele 5. Systém mění stav uživatelského účtu v databázi na hodnotu “Smazán” 6. Systém inkrementuje verzi účtu v databázi Zbytek fragmentu modelu případů užití, do kterého patří i uvedený scénář, uvádí obrázek 3.4. Roli actora zde má administrátor, který například narozdíl od servisního technika má právo s modulem správy uživatelů pracovat. Další rolí je vlastní systém licenčního serveru, který například při založení nového uživatele může zkontrolovat existenci obrazu nového účtu v LDAP databázi, je-li LDAP server online.
16
KAPITOLA 3. ANALÝZA
2. Systém bude poskytovat modul pro správu uživatelů
2.1. Modul bude umožňovat CRUD operace s uživatelskými účty
2.2. Modul bude umožňovat CRUD operace se skupinami uživatelů
2.3. Modul bude umožňovat přiřazování uživatelů do skupin
2.4. Modul bude umožňovat odebírání uživatelů ze skupin
Obrázek 3.3: Fragment modelu požadavků na modul správy uživatelů
17
3.2. SPRÁVA UŽIVATELŮ
Modul správy uživatelů
Zobrazit seznam uživatelů «include» Administrátor Upravit uživatele «include»
Smazat uživatele Vytvořit uživatele
«extend» Najít uživatele v LDAP databázi System
Obrázek 3.4: Případy užití modulu správy uživatelů
18
KAPITOLA 3. ANALÝZA
Kapitola 4
Návrh řešení 4.1
Systémová architektura
Hrubý náhled na nový systém jsme již udělali v sekci 2.2. Nyní detailněji popíšeme komponenty a změny v nové architektuře systému.
4.1.1
Diagnostická aplikace
Diagnostická desktopová aplikace tvoří klientskou část systému. Musí být flexibilní ve smyslu takovém, že bude svůj vzhled a povolenou funkcionalitu přizpůsobovat jednotlivým uživatelským rolím. Například role vývojáře musí korespondovat plně funkční desktopové aplikaci. Naopak role servisního technika od zákazníka bude pravděpodobně korespondovat smluvně domluveným SLA/SLS mezi firmou zákazníka a SELČ. Dalším důvodem pro flexibilitu grafického uživatelského rozhraní1 je optimalizace kognitivních a paměťových zdrojů koncového uživatele. Případy užití desktopové aplikace zůstávají stejné. Nově ale aplikace plní roli klienta2 serverové webové služby. Komunikace probíhá prostřednictvím standardizovaného formátu zpráv a pomocí standardizovaného rozhraní služby. To uživateli aplikace dává nové možnosti, jak diagnostickou aplikaci využívat ve chvíli, kdy je dostupná konektivita aplikace do internetu. Aplikace v tu chvíli pracuje v online módu. Mnohdy je ale situace problematičtější. To, že SELČ má zakázky po celém světě znamená, že i dopravní prostředky a jejich technici se nacházejí po celém světě. Konektivita do internetu mnohdy není dostupná například z důvodů typu legislativních restrikcí, špatného signálu nebo pomalé linky. V tu chvíli se ke slovu dostává druhý mód fungování diagnostické aplikace, takzvaný offline mód. V offline módu aplikace pracuje s tím, co má k dispozici a tím jsou historicky stažené licence a informace z doby, kdy byl server naposledy dostupný. Pokud funkcionalita offline módu nebude dostačující, bude třeba telefonicky kontaktovat zodpovědnou osobu, která bude schopna ve webové aplikaci licenčního serveru provést potřebné úkony a získané dočasné kódové slovo sdělit telefonicky nazpět technikovi, který ho využije k zpřístupnění potřebné funkcionality v aplikaci. 1 2
dále jen GUI neboli konzumenta v terminologii webových služeb
19
20
KAPITOLA 4. NÁVRH ŘEŠENÍ
4.1.2
Informační systémy
Nový systém využívá staré informační systémy povětšinou stejným způsobem jako doposud. Obraz konfigurace software je mezi systémy rozprostřen a ty navíc obsahují pro diagnostickou aplikaci cenná data, kterými jsou například zdrojové kódy, výsledný software, kusovníky a balíčky verzí. Naopak ze strany diagnostické aplikace jsou systémy využívány pro upload získaných diagnostických dat. Mediátorem obou těchto stran je právě licenční server. Nově ale systém do celého procesu užívání diagnostické aplikace zapojuje další informační systémy, například z důvodu bezpečnosti. Autentizační data jsou v LDAP databázi a autorizační data v interní databázi licenčního serveru. Autentizační data je třeba replikovat do interní databáze, protože jinak by v systému existoval takzvaný single point of failure3 .
4.1.3
Řídicí jednotky
Motivací celého rozsáhlého systému je stále jediná hlavní věc - dopravní prostředky a jejich bezproblémový provoz. V dnešní době, kdy dopravní prostředky jsou řízeny elektronikou a počítačem, klesá podíl “fyzikálních” problémů a přibývá problémů “počítačových”. K řešení takových problému již tedy nestačí holé ruce, selský rozum a zručnost, nýbrž je třeba odpovídající diagnostická výbava a know-how. Role řídících jednotek v dopravních prostředcích je jen těžko opomenutulná. Příklad takové jednotky ukazuje obrázek 4.1 a jako taková se jednotka může skládat z několika částí [3]: Programovatelné obvody. Například FPGA nebo CPLD. Jde o programovatelná hradlová pole, která se konfigurují a programují sériovým konfiguračním bitstreamem. Takovým bitstreamem je výsledný softwarový produkt určité verze, takzvané CA. Procesory. Jde například o typy DSP, CPU nebo MCU. Tyto obvody ve své paměti obsahují program, který vykonávají. Typicky připadají dvě CA na jeden procesor. Přepisovatelnou paměť. Takovou pamětí může být například paměť typu EEPROM. V ní se nachází údaje o typu, provedení jednotky, provedení plošného spoje, kusovníku a sériové číslo. Záznam do paměti zapisuje výstupní kontrola výrobce. Nesmazatelný unikátní identifikátor. Neboli UID. Je vypálen laserem při výrobě čipu ještě před jeho zapouzdřením. Paměti pro parametry. Z těchto pamětí diagnostická aplikace hodnoty parametrů čte a naopak do nich zapisuje jejich hodnoty. Paměti pro archiv událostí. Zde jsou uloženy záznamy, pořízené při zachycení chyby během provádění programu. Jejich analýza umožňuje odhalení vzniklé chyby, její opravu a předcházení budoucím problémům. RTC obvody. Neboli obvody reálného času. Všechny procesory by v budoucnu měly mít přímý přístup na RTC tak, aby mohl chybové záznamy ukládat se správnou časovou značkou. 3
zkráceně SPOF
4.2. SERVEROVÁ ARCHITEKTURA
21
Obrázek 4.1: Řídící jednotka
4.2
Serverová architektura
Softwarová architektura serveru musí být navržena tak, aby vyhověla všem architektonickým požadavkům. Na systém by se mělo jít dívat jako na modulární framework, který jasně definuje služby které poskytuje, ale zároveň neklade omezení při volbě použitých technologií. To je částečně umožněno i díky systému balíčků4 , které funkcionalitu serveru vhodně separují a udržují jí přehlednou. I využití návrhových vzorů výrazně podporuje robustní architekturu aplikace.
4.2.1
Řešení architektonických požadavků
Open source. Server bude vyvíjen tak, aby společnost ŠKODA ELECTRIC měla přístup ke zdrojovým kódům aplikace. Systém se totiž v budoucnu určitě bude rozšiřovat o další funkcionality. Pro tyto účely byl využit distribuovaný verzovací systém Mercurial, do kterého jsou úpravy zdrojového kódu a aplikace jako celek pravidelně ukládány. Mercurial podporuje i práci offline, což pohodlně umožňuje práci na aplikaci odkudkoliv. Čitelnost kódu je podpořena objektovým paradigmatem, protože systém je vývíjen jako objektově-orientovaný. Na vyšší úrovni abstrakce funguje systém balíčků, které vhodně sdružují třídy, které spolu 4
z angl. package system
22
KAPITOLA 4. NÁVRH ŘEŠENÍ
věcně souvisí. Aplikace je navíc psána v jazyku Java, který, jak známo, uvolnil před několika lety své zdrojové kódy veřejnosti a je vyvíjen jako open source. Licenční server dále využívá několik knihoven, z nichž všechy jsou open source frameworky pro tvorbu aplikací. Nezávislost. Nezávislostí serveru je myšleno využívání jeho služeb z libovolné platformy a v libovolném prohlížeči, které budou umožňovat plnohodnotnou práci jak s webovou aplikací licenčního serveru, tak s webovou službou licenčního serveru. Potřeba nezávislosti je v dnešní době motivována velkým a rostoucím počtem webových prohlížečů, které jsou u uživatelů oblíbené. Rozdíly ve výsledném zobrazení webových stránek jsou pro uživatele totiž rušívým elementem a množství těchto rozdílů je stále příliš velké na to, aby o rozdílech mohl vědět každý vývojář. V licenčním serveru nuance mezi prohlížeči elegantně zakrývá webový framework Vaadin, který z jazyku Java výsledný kód pro interpretaci webovým prohlížečem5 generuje v souladu se standardy konsorcia W3C, kterými by se vývojáři webových prohlížečů měli řídit. Nadto je použitý framework Vaadin při svém vývoji intenzivně manuálně i automatizovaně testován na shodu zobrazení v různých prohlížečích. Iluze jedné ze základních vlastností jazyka Java, platformové nezávislosti, je tedy i zde prakticky dokonalá. Pod nezávislostí v konzumování webové služby je třeba chápat komunikaci pomocí standardizovaných protokolů, hladký průchod sítí a standardizované rozhraní. O řešení detailně pojednává sekce 5.3. Rozsiřitelnost. Požadavek úzce související s modularitou a s výhledem na budoucí rozšiřování aplikace. Špatně navržená aplikace by totiž vedla k podobným nedostatkům, které má současný monolitický system. Rozšiřitelnost patří spolu s čitelností, robustností, atd. k produktům dobré softwarové architektury. Tento požadavek lze tedy řešit myšlením na budoucnost už dnes při tvorbě kódu. Kontrolování stability a konzistence architektury po každém větším zásahu do zdrojového kódu, dobrá dokumentace a brainstorming potenciálního budoucího rozšiřování udržují systém rozsiřitelným. Modularita. Jednotlivé množiny funkcí serveru se dají dobře vydefinovat a proto je systém možno vytvořit modulárně s využitím knihoven a systému balíčku jazyku Java. Výsledkem potom je server jako modulární framework, u kterého není těžké měnit technologie jednotlivých modulů a vrstev. Systém díky tomu lze členit pomocí mnoha hledisek a pracovat s ním pomocí pohledů6 . Jmenujme například Frontend a Backend jako pohled klienta webové aplikace licenčního serveru nebo Model, View, Controller jako pohled na zodpovědnosti vrstev aplikace. Výkon. Výkon aplikací dnes v komerční sféře rozhoduje o jejich úspěchu či neúspěchu. Jde především o ovlivňování uživatelské zkušenosti7 , která, pokud je špatná, může vést k úbytku počtu uživatelů a hledání substitutů. Odhad budoucí zátěže na licenční server v pracovní době8 sice není velký, ovšem pro zajištění dostatečného výkonu na straně serveru je třeba výpočetně náročné akce provádět mimo pracovní dobu. To umožňuje přidělení většího 5
mluvíme o (X)HTML stránkách, souborech stylů CSS a JS souborech skriptovacího jazyka Javascript z angl. views 7 z angl. user experience 8 z angl. business hours 6
4.2. SERVEROVÁ ARCHITEKTURA
23
kvanta výpočetního výkonu pro renderování interaktivního GUI a použití technologií, které mají nemalé požadavky na paměť a procesorový čas serveru. Lokalizace. Systém nebude anticipovat nic o jazykových znalostech techniků, kteří ho používají. Kromě rozhraní v českém jazyce tedy bude nabízet i rozhraní v angličtině a možnost přidání nového jazyka by měla být co nejjednodušší. To ostatně souvisí s již zmíněnou rozšiřitelností systému. Pro naplnění tohoto požadavku lze využít systém Resource bundles jazyka Java, který na základě zjištění preferovaného jazyka klientského prohlížeče vybírá textový soubor se zprávami v příslušném jazyce. Druhou a zvolenou možností je nadstavba myšlenky Resource bundles ve frameworku Vaadin, kterou jsou v hantýrce developerů Vaadinu nazývané Messages třídy. Ty obsahují lokalizované zprávy, ke kterým se přistupuje pomocí dynamicky generovaných klíčů. Dokumentace. Celý systém by měl být kvalitně zdokumentován. Je to nutnost jak dle interních firemních směrnic, tak dle zdravého rozumu v situaci, kdy se vyvíjí libovolná větší a sebedůležitější aplikace. Programovací jazyk Java inherentně svůj úspěch staví na kvalitní dokumentaci a pro vývojáře nabízí systém Javadoc, který z poznámek ve zdrojovém kódu generuje kvalitní a přehlednou dokumentaci ve formátu HTML. Potenciální rozšiřovatelé licenčního serveru tedy nebudou muset projít systémem “reverzního inženýrství” předtím, než se pustí do úprav stávajícího zdrojového kódu a přidávání kódu nového. Bezpečnost. Bezesporu nejdůležitějším požadavekem, který byl stimulem pro rozhodnutí o vývoji serveru, je bezpečnost. Bezpečnosti je věnována celá sekce 5.4. Zde pouze zmíníme, že je třeba mít na paměti věci jako zabezpečení komunikace mezi klientem a serverem, autentizaci, autorizaci a logování uživatelů, obranu před útoky na server atd.
4.2.2
Vzory
Projekt licenčního serveru využívá hned několik vzorů. Ty totiž podporují tvorbu kvalitního software, který je díky tomu vytvářen v souladu s paradigmatem Best practice. Protože požadavků na licenční server je mnoho, tak vzory citelně celý proces jeho tvorby zjednodušší, zpřehlední a sjednotí. Vzory dělíme do kategorií podle mnoha různých kritérií. Existují tak například vzory požadavků, programovací styly, vzory konkrétních domén a jazyků, GRASP vzory, architektonické vzory a návrhové vzory9 GoF a Enterprise. GoF vzory byly průkopníky návrhových vzorů, pojmenovány jsou podle autorů Ericha Gammy, Richarda Helma, Ralpha Johnsona and Johna Vlissidese. Enterprise vzory rozšiřují množinu návrhových vzorů pro specifický typ aplikací, konkrétně Enterprise aplikace. Za jejich autora je považován Martin Fowler. Licenční server používá několik vzorů z různých kategorií, uvedeme proto vždy jen jednoho reprezentanta a důvod jeho použití: 9
z angl. design patterns
24
KAPITOLA 4. NÁVRH ŘEŠENÍ
4.2.2.1
Model, View, Controller
Architektonický vzor, kterému se zkráceně říká MVC. Jeho hlavním úkolem je separace business logiky a stavu aplikace (Model) od prezentace dat uživateli přes uživatelské rozhraní (View). Tato myšlenka výrazně snižuje provázanost těchto dvou vrstev aplikace a umožňuje se na ně lépe dívat právě optikou vrstevnatého modelu. Třetí komponentou vzoru je takzvaný Controller, který má za úkol obsluhovat požadavky, přicházející od uživatele z rozhraní a reagovat na ně. Při reagování se může zároveň dotazovat Modelu. Controller tedy tvoří řídící komponentu celého vzoru. V licenčním serveru je tento vzor použit s drobnými úpravami, plynoucími z kontextu a komponentové orientace UI frameworku Vaadin. Controller je tvořen servletem ApplicationServlet frameworku Vaadin, který příjímá klientské požadavky komunikací typu AJAX. Controller má přímý odkaz na hlavní okno aplikace a diriguje změny v komponentovém modelu na serveru, který se zpětně AJAX komunikací promítá do webového prohlížeče užvatele. V případě potřeby Controller upravuje stav aplikace, čímž mění její datový model. Celou situaci pomocí UML modelu komponent ukazuje obrázek 4.2.
Web browser
LicenseServer
ApplicationServlet MainScreen LicenseServer:: VehicleType LoginScreen LicenseServer:: Unit DBAccessPoint
Obrázek 4.2: Diagram komponent vzoru MVC v kontextu licenčního serveru
4.2.2.2
High Cohesion
GRASP vzor, který přiřazuje zodpovědnosti třídám tak, aby zůstala jejich soudržnost vysoká. Jde tedy o vydefinování množin věcně souvisejících funkcionalit. Každá tato množina následně bude implementována jako samostatná třída. Zřejmě tedy jde o nalezení optimálního bodu ve škále mezi jedinou třídou, která by zastupovala funkcionalitu celé aplikace a vysokou granularitou v podobě malých tříd, z nichž každá by řešila jedinou elementární funkci a proto musí často komunikovat s okolními třídami, aby aplikace fungovala jako celek. To je také důvod, proč vzor souvisí s dalším GRASP vzorem - Low Coupling.
25
4.2. SERVEROVÁ ARCHITEKTURA
Jako ukázku takové třídy v licenčním serveru předkládáme třídu CryptoUtil, která má zodpovědnost za bezpečnostní operace šifrování, dešifrování a tvorbu otisků. Už tato definice záběr třídy jasně specifikuje a třída díky tomu má optimální počet proměnných a jasně definovanou funkcionalitu. Protože je třeba zajistit, že webová aplikace i webová služba budou pracovat s stejnou instancí třídy CryptoUtil, je tato třída implementována jako GoF návrhový vzor Singleton. Obrázek 4.3 třídu vizualizuje.
CryptoUtil -
generator: Random rsaCipher: Cipher publicKey: PublicKey privateKey: PrivateKey instance: CryptoUtil webinfFolder: String
+ + + + + + + + + + + +
getInstance() : CryptoUtil getHash() : byte[] generateSalt() : byte[] generateIterations() : int hexEncode(byte[]) : String hexDecode(String) : byte[] loadKeys() : void generateKeys() : void encrypt(byte[]) : byte[] decrypt(byte[]) : byte[] getPublicKey() : PublicKey createSignature(byte[], String, int) : String
Obrázek 4.3: Třída CryptoUtil
4.2.2.3
View Manager
J2EE návrhový vzor pro WEB2.0 aplikace s komplexním grafickým uživatelským rozhraním, postaveným na komponentové orientaci. Takové RIA aplikace totiž poskytují uživateli interaktivitu a pocit z práce blížící se desktopové aplikaci. Ovšem platformou takové aplikace je stále web, spolu se všemi omezeními HTTP protokolu, generováním a zobrazováním HTML stránek atd. Tento nesoulad se alespoň v oblasti změn jednotlivých obrazovek/screenů snaží řešit tento vzor. V licenčním serveru jsou implementovány metody pro inicializaci obrazovky, změny obrazovky, vrstvení layoutů, odebírání layoutů a získání aktuálně vrchní obrazovky. Celá třída je zobrazena jako model na obrázku 4.4. 4.2.2.4
Concrete Table Inheritance
Enterprise vzor, který úzce souvisí s trendem posledních let, objektově-relačním mapováním. ORM vyplňuje sémantickou mezeru mezi aplikačním kódem a dnešními leadery na trhu - relačními databázemi. Často je totiž třeba data v instanci aplikační třídy persistentně uložit
26
KAPITOLA 4. NÁVRH ŘEŠENÍ
ViewManager -
views: HashMap<String, Layout> screenStack: Stack
window: Panel
+ + + + +
init() : void switchScreen(String, Layout) : void pushScreen(String, Layout) : void popScreen() : void getWindow() : Panel
Obrázek 4.4: Třída ViewManager
do databáze, ať už přesně v poměru 1:1 s databázovým řádkem nebo s drobnými úpravami. Pro ORM v jazyce Jave existuje norma JSR 317, kterou by implementace této normy, JPA frameworky, měly dodržovat. Vzor Concrete Table Inheritance definuje mapování vazby dědičnosti z aplikačního kódu do databáze tak, že výsledkem bude pro každou neabstraktní třídu relace s množinou atributů, vznikou sjednocením fieldů původních aplikačních tříd, mezi kterými vazba dědičnosti směrem ke kořeni byla. Pro tvorbu licenčního serveru byl tento vzor zvolen ze dvou důvodů. První je zřejmý, v modelu tříd existuje vazba dědičnosti mezi třídou CommonEntity a skoro všemi ostatními třídami. Třída CommonEntity definuje pro tyto entitní třídy společné proměnné a tudíž sémantiku vazby dědičnosti musíme nějakým zůsobem zachovat i v databázi. Druhým důvodem už bylo pouze rozhodování mezi možnými variantami mapování a porovnání jejich výhod a nevýhod vzhledem k vytvářené aplikaci. Protože potřebujeme mít v databázi společné atributy ve skoro každé další relaci vyjma CommonEntity, která tvoří abstrakci, byl zvolen vzor Concrete Table Inheritance, který přesně tyto požadavky jako jediný splňuje10 . Obrázek 4.5 zobrazuje mapování třídy CommonEntity a třídy MetaParam na databázovou tabulku MetaParam. 4.2.2.5
Proxy
GoF návrhový vzor, který poskytuje zástupný objekt vzdálenému objektu. Typické použití Proxy je v síťové infrastruktuře, kdy zástupný objekt tvoří lokálního agenta, se kterým klient komunikuje a odstiňuje ho od potenciálních problémů sítě či severu, na kterém je uložen objekt skutečný. Aplikace díky tomu nemusí o existenci síťové infrastruktury vůbec vědět a to snižuje její komplexitu. Nutnost odchytávání a reagování na potenciální chyby objem potřebného kódu totiž značně zvyšuje. Webová aplikace licenčního severu Proxy přímo nevyužívá, ale Proxy je implementována do knihovny klientské aplikace webové služby. Diagnostickou aplikaci tedy odstiňuje od existence sítě a SOAPoverHTTP komunikace a navíc umožňuje pohodlné testování diagnostické 10
alternativními vzory jsou Single Table Inheritance a Class Table Inheritance
27
4.2. SERVEROVÁ ARCHITEKTURA
CommonEntity -
id: long version: long comment: String MetaParam
MetaParam -
«column» * id name defaultValue version comment
name: String defaultValue: String
Obrázek 4.5: Vzor Concrete Table Inheritance v kontextu licenčního serveru
aplikace nezávisle na existenci nebo dostupnosti serveru. Jako forma implementace byly zvoleny dvojice odpovídajících metod v implementační třídě rozhraní knihovny. Jedna z metod reaguje na požadavek diagnostické aplikace a podle stavu dostupnosti serveru vrací skutečný výsledek nebo chybu. Druhá z metod představuje reálné volání vzdálené metody pomocí SOAPoverHTTP komunikace. Tento koncept11 ukazuje obrázek 4.6. «interface» LicenseClient + + +
login(String, byte[], URL) : void getLicenseList() : List getLicense(Long) : byte[] LicenseClientImpl -
port: LicenseService service: LicenseService_Service
+ + + + + +
login(String, byte[], URL) : void loginImpl(String, byte[], URL) : void getLicenseList() : List getLicenseListImpl() : List getLicense(Long) : byte[] getLicenseImpl(Long) : byte[]
Obrázek 4.6: Rozhraní a implementace knihovny klientské aplikace
4.2.3
Systém balíčků
Vlastnosti modularity a dobrého komponentového návrhu musí v programovacím jazyce být nějakým způsobem podpořeny. Jazyk Java pro tento účel nabízí systém balíčků, který licenční server ve velkém množství využívá. Kód aplikace tím na nejvyšší úrovni abstrakce 11
pro přehlednost nejsou zobrazeny všechy metody
28
KAPITOLA 4. NÁVRH ŘEŠENÍ
rozděluje na webovou službu a webovou aplikaci. Webová aplikace se dále dělí na třídy pro GUI a třídy, které fungují jako pomocné nástroje webové aplikace (jde například o EIS vrstvu, která poskytuje rozhraní k externím systémům nebo o Model aplikace, obsahující entitní třídy). Další dělení najdeme na úrovni GUI, kdy například byla separována logika řízení zobrazování jednotlivých obrazovek a množina konkrétních předdefinovaných obrazovek. Fragment hierarchie balíčků ukazuje package model na obrázku 4.7. cz.skoda.alpha
ws
ls
ui
eis
screens
model
util
Obrázek 4.7: Fragment hierarchie balíčků
4.3
Datový model
Licenční server pracuje s nejrůznějšími daty, která musí často být persistentní. Jmenujme například uživatelské účty, skupiny, licence, záznamy o změnách a událostech nebo informace o dopravních prostředcích a jednotkách. Realizaci dedikovaného datového úložiště popisuje kapitola 6. Zde uvedeme aktuální verzi datového modelu, vytvářeného na základě sběru požadavků na licenční server a na základě identifikace objektů, které potřebují být uloženy v databázi, tedy takzvaných entit. Používanou notací je UML Class diagram a model se snaží zachytit datové úložiště z pohledu aplikace. Důvodů pro tento přístup k modelování je více. Těmi hlavními jsou abstrahování od diskuzí o implementačních detailech SQL a použití ORM frameworku dle standardu JPA, který toto abstrahování řeší i ve fázi implementace [7]. K detailům SQL databáze se tedy dostaneme pouze v případě, kdy bude třeba nějakým způsobem optimalizovat frameworkem vygenerovaný výsledek nebo například vytvářet indexy pro zrychlení vyhledávání podle neklíčového atributu. Všechy tabulky totiž mají jako primární klíč identifikátor typu Long dle konvence, mnohdy však entity lze identifikovat pomocí jiných
29
4.3. DATOVÝ MODEL
neklíčových atributů, podle kterých je navíc třeba vyhledávat záznamy. Datový model je v některých partiích založen na paradigmatu metatříd, známého z objektového programování. Prefixy tříd Meta, Class a Object tedy znamenají přesně to samé, co v OOP. Celkový pohled na datový model lze najít na přiloženém CD, zde pro přehlednost procházíme model po jeho jednotlivých důležitých částech. Na závěr dáme všechy části do souvislostí.
4.3.1
Speciální entity
User -
username: String password: String firstName: String lastName: String company: String status: String lastModified: Date ldapChecksum: String ldapRef: Reference salt: String iterationCount: int
LogEvent -user
-committedEvents
1
0..*
-
id: long fromVersion: long timestamp: Date
CommonEntity -events 0..*
-target 1 -
id: long version: long comment: String
Obrázek 4.8: Speciální entity Obrázek 4.8 zobrazuje fragment modelu, na kterém jsou tři entity se speciálním výnamem v aplikaci: CommonEntity. Entita, která sama o sobě persistentní není, protože je abstraktní a zvolená metoda mapování dědičnosti jí do výsledných SQL tabulek nezahrne. Tvoří ale předka všech ostatních entit12 , pro které definuje společné atributy, které slouží jako identifikátor, verzovací pole a prostor pro doplňující poznámky. LogEvent. CRUD operace nad libovolnou entitou v systému musí být dohledatelné. Každá entita tedy je ve vztahu s touto entitou, reprezentující příslušnou CRUD operaci spolu s verzí a časovou značkou. Tato entita nemá předka. User. Uživatel systému13 , jehož speciální význam tkví ve skutečnosti, že každá CRUD operace má svého iniciátora. To je důvod vazby mezi entitami User a LogEvent. Entita dále definuje základní atributy uživatelských účtů a jejich případné obrazy v LDAP databázi.
4.3.2
Licence a projekty
Obrázek 4.9 zobrazuje fragment modelu, na kterém jsou entity, související s projekty SELČ a generováním licencí: ClassProject. Konkrétní koncové projekty zákazníků SELČ. 12 13
vyjma asociačních tříd a třídy LogEvent včetně systému samotného
30
KAPITOLA 4. NÁVRH ŘEŠENÍ
Unit
UID
1
1 -units
-vehicles
MetaProject baanData: Reference top: boolean
0..*
0..*
-
type: String
0..*
0..*
1 -
0..* 0..*
0..*
0..*
ECUType
VehicleType
0..1 -
0..1
1 0..*
0..* CA
ClassProject
-cas
0..* -
weight: int RAM: String consumption: int
SIN
0..1
0..*
LicenseGeneration
name: String versionString: String
0..* 0..* -
1 0..* 0..*
issued: Date expires: Date active: boolean signature: String licenseFile: Clob salt: String iterationCount: int
0..*
ObjectProject
-deactivator 1
-license LicenseDownload 1
0..* -
0..*
0..* -issuer 1
timestamp: Date method: String
0..* -issuedLicenses 1
User 1
0..*
1
Obrázek 4.9: Licence a projekty
MetaProject. Rodičovské projekty k projektům koncovým. Takový projekt může být zároveň takzvanou vrcholovou zakázkou, což se pozná dle hodnoty atributu top. Projekty jsou obrazy reálných zakázek, zanesených do systému Baan. ObjectProject. Úpravy projektu v rámci aplikace licenčního serveru. VehicleType. Typ vozidla, ve kterém jsou řídicí jednotky v rámci daného projektu nasazeny. Můze jít o různé typy vlaků, metra, tramvají apod. CA. Firmware/software procesorů a hradlových polí řídicích jednotek. Unit. Řídící jednotka. SIN. Jedno z možných identifikačních čísel jednotek. UID. Jedno z možných identifikačních čísel jednotek. ECUType. Interní typovník elektronických řídicích jednotek. Obsahuje například údaje o velikosti paměti, váze, spotřebě a označení typu. LicenseGeneration. Záznam o vygenerování licence. Na tento záznam se váží údaje o uživatelích, kteří licenci vytvořili, deaktivovali nebo jim byla vydána. LicenseDownload. Záznam o stažení licence. Stažení lze provést hned několika způsoby. Soubor může být stažen prostřednictvím webové služby nebo pomocí webové aplikace. Oba způsoby je třeba rozlišit a okamžik stažení spolu s uživatelem identifikovat.
4.3.3
Role a skupiny
Obrázek 4.10 zobrazuje fragment modelu, na kterém jsou entity, reprezentující role a skupiny v aplikaci a síti SELČ:
31
4.3. DATOVÝ MODEL
User 1
0..*
ObjectRole -
name: String from: Date to: Date state: String priority: int
0
0..*
ObjectUserGroup
0..1 -
name: String memberCount: int defaultPriority: int
Connection 0..* -
1
from: Date to: Date priority: int
0..*
0..*
1..*
-prototypes 1 1
UserState
ClassRole -
name: String 0..*
-roles
0..*
ClassUserGroup
0..* 0..1
-
ldapRef: Reference ldapModified: String ldapChecksum: String 1
0..*
0..* 1
-
state: Enum expires: Date
0..* 0..*
ClassOrganization ClassProject
Obrázek 4.10: Role a skupiny
ObjectRole. Uživatelská role v aplikaci, ke které se zároveň váží povolené a zakázané akce v řídící jednotce. Taková role může mít časově omezenou platnost, může se nacházet v různých stavech a má svoji implicitní prioritu, která se použije při vyhodnocování konečné možiny akcí vstupujících do licence. ClassRole. Prototyp uživatelské role v aplikaci, který umožňuje úpravy akcí a parametrů z prototypové akce. ClassOrganization. Pro určité typické modely zákaznických společností tato entita dovoluje vhodně předdefinovat množiny rolí, které se ve společnosti typicky vyskytují. To usnadňuje další práci a manipulaci. ObjectUserGroup. Skupina uživatelů v licenčním serveru. ClassUserGroup. Skupina uživatelů jako obraz skupiny z LDAP databáze. Connection. Asociační třída, která definuje dodatečné atributy příslušnosti uživatele do skupiny ObjectUserGroup. Lze předefinovat dobu příslušnosti do skupiny a prioritu pro vyhodnocování akcí, kterou v ní uživatel bude mít. Administrátor díky tomu má možnost ovlivnit výsledek generované licence na úrovni konkrétních uživatelů. UserState. Definuje způsob, jakým se uživatel dostal do skupiny ClassUserGroup. Lze totiž takový uživatelský účet přímo získat jako obraz z LDAP databáze nebo lze například uživatelský účet ve webové aplikaci licenčního serveru založit jako dočasný do doby, než ho ŠKODA ICT založí v LDAP databázi.
32
KAPITOLA 4. NÁVRH ŘEŠENÍ
«Group» Customization ObjectRole ObjectParam -
value: String
ObjectAction
-params 1 -
0..*
0..*
name: String disable: char
-actions 0..*
1
0..* 0..*
1 ClassParam -
«Group» Template
-actions -
0..*
0..*
1
0..*
1
1
MetaParam name: String defaultValue: String
name: String
1
0..*
-
ClassRole
ClassAction
-params
value: String
-prototypes 1
1
MetaAction -params 0..*
-
name: String
1
Obrázek 4.11: Akce a parametry
4.3.4
Akce a parametry
Obrázek 4.11 zobrazuje fragment modelu, na kterém jsou entity, reprezentující akce a jejich parametry v rámci řídících jednotek: ClassAction. Konkrétní akce v řídící jednotce v kontextu aplikace DisMon. ClassParam. Přepsání implicitního parametru v případě, že nevyhovuje. MetaAction. Prototyp akce s předdefinovanými implicitními parametry. MetaParam. Implicitní hodnota parametru. ObjectAction. Dodatečná možnost pro úpravu akce. ObjectParam. Dodatečná možnost pro úpravu parametru.
4.3.5
Shrnutí
Celkový model lze poskládat pomocí propojovacích entit, které jsou v jednotlivých fragmentech vidět. Model se tedy skládá ze 4 jmenovaných oblastí, nejdůležitější entitou je uživatelský účet User, od kterého se odvíjí mnoho vazeb na další entity. Datový model ukazuje souvislost uživatelů a jejich rolí a skupin. Role se váží k akcím a parametrům, což administrátorovi šetří čas při vlastní tvorbě licence, která probíhá vytvořením množiny akcí z uživatelských rolí. Skupiny se potom váží k projektům zákazníků SELČ. V projektech lze dohledat konkrétní jednotky a software, který zákazníkovi byl dodán a zákazník má právo ho používat. Z těchto údajů je systém už schopen generovat licence. Na závěr přidáváme popis některých, na první pohled ne zcela samovysvětlujících atributů, které se v datovém modelu vyskytují, v tabulce
33
4.3. DATOVÝ MODEL
4.1 a v tabulce 4.2 s obrázkem 4.12 stavy, ve kterých se uživatelský účet může nacházet vzhledem ke své skupině ClassUserGroup 14 . Atribut CUG.ldapChecksum CUG.ldapModified CUG.ldapRef ObjectAction.disable User.ldapChecksum User.ldapModified User.ldapRef User.status
Popis Kontrolní součet údajů z LDAP databáze Datum poslední aktualizace z LDAP databáze Pointer do LDAP databáze na kontext, odpovídající dané skupině Symbol definující, zda má být akce odstraněna z množiny oprávnění Kontrolní součet údajů z LDAP databáze Datum poslední aktualizace z LDAP databáze Pointer do LDAP databáze na kontext, odpovídající dané skupině Stav uživatelského účtu (aktivní, zablokovaný, zrušený)
Tabulka 4.1: Speciální atributy v datovém modelu Stav ADDED REMOVED COPIED TMPADDED
Popis Uživatelský účet založen v licenčním serveru a v LDAP databázi nikoliv Uživatelský účet smazán v licenčním serveru a v LDAP databázi nikoliv Uživatelský účet odpovídá svému obrazu v LDAP databázi Uživatelský účet byl vytvořen pouze pro účely licenčního serveru
Tabulka 4.2: Stavy uživatelského účtu vzhledem ke skupině ClassUserGroup
14
zkratka CUG značí ClassUserGroup
34
KAPITOLA 4. NÁVRH ŘEŠENÍ
Vytvoření [Obraz účtu v LDAP databázi není plánován] /Určení data expirace účtu
Vytvoření [Obraz účtu nelze najít v LDAP databázi]
Vytvoření [Obraz účtu lze najít v LDAP databázi]
TMPADDED
ADDED
COPIED Založení v LDAP databázi
Smazání
Smazání
REMOVED
Obrázek 4.12: Stavový diagram uživatelského účtu
Smazání
Kapitola 5
Implementace 5.1
Webové rozhraní
Z pohledu uživatele je webové rozhraní jediným hmatatelným důkazem o existenci licenčního serveru, protože v případě práce s aplikací DisMon uživatel používá server nepřímo a od jeho existence je tedy odstíněn. Webové rozhraní nachází své uplatnění v různých situacích v závislosti na konkrétním uživateli a jeho rolích. Například servisní technik bude webové rozhraní využívat nejčastěji pro stažení svých licencí, které k práci potřebuje. Naopak administrátor zákaznické společnosti bude spravovat uživatelské účty členů jeho skupiny a stahovat licence pro své kolegy, kteří licence zrovna potřebují.
5.1.1
Technologie
Webové rozhraní je vytvářeno výhradně pomocí frameworku Vaadin. Jde o techologii, která většinu práce odvádí na serverové straně. To jí odlišuje od technologií, které jsou postaveny na skriptech ve webovém prohlížeči1 . Fungování na straně serveru dává Vaadinu mnohé možnosti, které by lokálně v prohlížeči nebyly myslitelné. Ovšem stinnou stránkou je zřejmé úzké hrdlo výpočetního výkonu, který při použití frameworku Vaadin musí na serveru centrálně vypočítávat rozhraní pro všechny připojené klienty. Zátěž tedy do značné míry není offloadována do webových prohlížečů jako v případě použití jiných frameworků a tak trochu je tedy porušována jedna ze základních myšlenek WWW služby na internetu. Architekturu frameworku ukazuje obrázek 5.1. Z architektury je vidět hned několik důležitých skutečností [4]: Komunikace. Klient a server komunikují pomocí protokolu HTTP. Vlastní data rozhraní jsou přenášeny v alternativním formátu k XML, formátu JSON, který více šetří paměťové a přenosové zdroje. Pro popis rozhraní jsou navíc ještě přenášena další data ve formátu UIDL, který je interním formátem frameworku Vaadin. GWT. Komponenta frameworku Vaadin a zároveň samostatně použitelný framework pro uživatelská rozhraní. Vaadin ho využívá jako vykreslovací knihovnu v uživatelově prohlížeči, aby co nejvíce minimalizoval výpočetní nároky na server. 1
s jednou z takových technologií Vaadin však funguje v symbióze
35
36
KAPITOLA 5. IMPLEMENTACE
Obrázek 5.1: Architektura frameworku Vaadin
Client-side Engine a Teminal Adapter. Komponenty frameworku, které zajišťují jeho veledůležitou schopnost vyměňování komponent mezi klientem a serverem. Komponenty a jejich změny jsou aktualizované v reálném čase díky technologii AJAX. Na straně serveru se na komponenty díváme jako na Java POJOs a na straně webového prohlížeče jsou komponenty tvořeny pomocí XHTML kódu, stylů a skriptů. Mapování a synchronizace mezi nimi je tedy základem frameworku. Komponenty. Na serverové straně framework nabízí množství předdefinovaných komponent, které na webu nacházejí uplatnění nejčastěji. Navíc přidává i komponenty, které jsou často používané v desktopových aplikacích, protože jde o framework pro WEB 2.0 aplikace. Díky dědičnosti je snadné rozšiřování komponent i tvorba komponent nových. Díky rozhraním s nimi framework umí ihned nakládat dle své potřeby. Témata. Vaadin poskytuje dvě základní témata, která sjednocují vzhled komponent a celého rozhraní, což působí pozitivně na zkušenost uživatele a zjednodušuje práci v rozhraní. Přidání nových témat nebo úprava stávajících je opět jednoduchou záležitostí, která je realizována pomocí kaskádových stylů. Vaadin tedy umožňuje tvorbu webových aplikací pomocí komponentového přístupu k vývoji desktopových aplikací [5]. Kromě již zmiňovaných výhod nabízí širokou vývojářskou komunitu, databázi pluginů a rozšíření pro náročné uživatele [12].
5.1.2
Organizace tříd
Logika uživatelského rozhraní je v licenčním serveru organizována tak, aby bylo možné ji snadno rozšiřovat o další části. Zároveň je třeba myslet na to, že veškerou logiku rozhraní tvoří třídy jazyka Java a nelze tedy přemýšlet stejně, jako kdyby vývoj probíhal pomocí
5.1. WEBOVÉ ROZHRANÍ
37
HTML/JSP stránek. Třídy jsou sdruženy do balíčků podle příbuznosti své funkcionality. Popis balíčků uvádí tabulka 5.1. Balíček components i18n panels screens util validators exceptions
Popis Komponenty, vytvořené pro účely aplikace Lokalizační data ve třídách plných zpráv Panely pro hlavní sekci rozhraní Obrazovky, zastřešující kompletní změnu rozhraní Doplňkové třídy, používané ostatními třídami Validátory pro kontrolu správnosti formulářových dat Výjímky pro chybové stavy webové aplikace Tabulka 5.1: Balíčky webového rozhraní
Panely v aplikaci slouží pro větší změny rozhraní v rámci jedné obrazovky. Příkladem takového panelu je pravá dolní část na obrázku 5.4, která je informačním rozcestníkem uživatele pro přihlášení a obsahuje i obrázek. Obrazovky v aplikaci slouži pro kompletní překreslování uživatelského rozhraní. Například přihlašovací obrazovku na obrázku 5.2 uživatel uvidí pravděpodobně jen jednou během procesu práce s webovou aplikací. Tato třída tedy přímo řeší nebo předává k řešení veškěré akce, které uživatel může žádat a které mohou nastat. Mluvíme například o výběru jazykové mutace rozhraní, přihlášení uživatele či zobrazení chybových hlášení v případě neplatných přihlašovacích údajů. V uspořádání tříd rozhraní lze za hierarchicky nejvýše postavenou považovat třídu, která zároveň je návrhovým vzorem - ViewManager. Už podle názvu lze odhadnout, že zodpovědností této třídy bude koordinace pohledů. ViewManager obsahuje zásobník, kterým na sebe vrství různá rozložení obrazovek tak, aby uživatel vždy viděl právě to, co potřebuje. Jde tedy o řízení obrazovek, které následně řídí panely, obsažené v příslušné obrazovce. Vidíme tedy víceúrovňový vztah závislosti tříd, který je pro přehlednost zobrazen na obrázku 5.3.
5.1.3
Organizace hlavní obrazovky
Vizuálně je rozhraní organizováno tak, aby bylo přehledné a snadno použitelné. Je abstrahováno od zbytečných detailů, které ruší pozornost uživatele. Na obrázku 5.4 proto vidíme organizaci hlavní obrazovky, kterou nyní popíšeme. Horní část. Zde je umístěno dvakrát logo společnosti ŠKODA. Místo mezi ním slouží jako oblast, zobrazující zprávy uživateli jako zpětnou vazbu na jeho akce. V pravé části jsou navíc ještě zobrazeny informace o aktuální session uživatele s možností jejího ukončení a odhlášení. Globální data uživatelské session jsou udržována a izolována od sessions ostatních uživatelů systémem přepínatelných referencí, které framework Vaadin nabízí jako takzvaný ThreadLocal návrhový vzor. Menu. Umístěno v levé části obrazovky, realizováno vertikálním systémem záložek a podzáložek2 . Menu je dvouúrovňové, přičemž první úroveň pouze logicky sdružuje podzáložky 2
z terminologii frameworku Vaadin mluvíme o harmonice, angl. accordion
38
KAPITOLA 5. IMPLEMENTACE
Obrázek 5.2: Přihlašovací obrazovka
z druhé úrovně a sama nemá žádný jiný funkční význam. Druhá úroveň již při výběru položky mění vzhled hlavní obrazovky, konkrétně přepíná mezi panely v pravé dolní části obrazovky. Menu v první úrovni obsahuje na výběr správu uživatelů, správu licencí, bezpečnostní klíče a obecné možnosti. Panelová část. Zbytek obrazovky, který tvoří většinu její plochy, je věnován panelům, které se systematicky mění v závislosti na požadavcích uživatele. Ten zde totiž stráví nejvíce času při práci s aplikací a tato část proto tvoří tak trochu uživatelovu pracovní plochu. Barevné téma. Aplikace používá lehce modifikovaný embedded motiv frameworku Vaadin - Runo theme. Studené barvy v kombinaci s oranžovými nadpisy a bullety menu první úrovně dohromady vytváří osobitý decentní vzhled.
5.1.4
Správa uživatelů
Uživatelské rozhraní podporuje hned několik podnikových procesů. Správa uživatelů zahrujne práci s uživatelskými účty, skupinami a rolemi na úrovni CRUD operací. Jako best practice v přístupu k vytváření dat v informačních systémech se ukazují být formuláře. Takový dobře navržený formulář by měl mít mnohé vlastnosti, mezi které patří: • Přehledné rozložení prvků • Samovysvětlující formulářová pole a jejich popisky
39
5.1. WEBOVÉ ROZHRANÍ
ViewManager
LoginScreen
WelcomePanel
MainScreen
AddUserPanel
UserDatabasePanel
Obrázek 5.3: Hierarchie tříd uživatelského rozhraní
• Decentní a přehledné zobrazování chyb • Možnost smazání dat a nového zahájení zadávání Přestože mezi vizuální stránku v životním cyklu formuláře patří defacto jen zobrazení jeho polí a případných chyb, tak framework Vaadin životní cyklus podporuje i v dalších etapách, kterými jsou například konverze dat a jejich validace. Validace dat je velice důležitým filtrem, který zabraňuje zaplňování databáze neužitečnými nebo nepoužitelnými daty. Mnoho validátorů je již ve frameworku předpřipraveno, některé je třeba rozšířit tak, aby odpovídali přesným normám organizace. Příklad takového formuláře uvádí obrázek 5.5 Zobrazování velkého množství dat je vhodné realizovat pomocí tabulek. Ty totiž data přehledně organizují do sloupců podle atributů jednotlivých záznamů. Vaadin si tuto skutečnost uvědomuje a poskytuje nástroje pro práci s tabulkami, mezi které patří: • Změna pořadí sloupců uživatelem • Snadné řazení záznamů podle sloupců • Stránkování tabulek s velkým počtem záznamů • Výběr konkrétních řádků tabulky Databáze uživatelů licenčního serveru, ukázána na obrázku 5.6, tabulku se všemi jejími vymoženostmi využívá. Akce úpravy záznamu většinou znamená načtení uložených dat zpět do formuláře, kde je možné je upravovat a uložit. Mazání záznamů je asi nejjednodušším úkonem, který většinou znamená jednu až dvě interakce s uživatelem. Pro obě poslední jmenované funkce jsou tabulky v licenčním serveru upraveny tak, aby u každého záznamu byla možnost jeho úpravy nebo smazání vidět, což dokládá i obrázek.
40
KAPITOLA 5. IMPLEMENTACE
Obrázek 5.4: Uvítací panel
5.2
Business logika
Business logikou licenčního serveru rozumíme část takzvaného backendu. Jde o vrstvu, jejíž existenci uživatel aplikace nevnímá. Přímo jí používá controller aplikace, kterým je servlet frameworku Vaadin. V licenčním serveru je business logika rozdělena do několika logických celků. Jde o třídy, komunikující s externími informačními systémy3 a pomocné třídy.
5.2.1
Přístupové body
Licenční server momentálně funguje v roli klienta pro tři systémy - dedikované datové úložiště, mirror databáze systému Baan a LDAP server. Přístupové body jsou inicializovány při startu aplikace v hlavním servletu LicenseServerApp. Konfigurace, nutná pro jejich inicializaci je uložena v textových souborech a načítána v okamžiku inicializace. Za běhu serveru tedy není možné přístupové body reinicializovat. Celkově v kontextu přístupových bodů hovoříme o EIS vrstvě. 5.2.1.1
LDAPAccessPoint
LDAP server zabezpečuje online autentizaci uživatelů webové aplikace i webové služby licenčního serveru. Serverem rozumíme Active Directory, implementaci adresářových služeb LDAP firmy Microsoft včetně jeho interní implementace LDAP databáze. 3
takzvané přístupové body, angl. access points
5.2. BUSINESS LOGIKA
41
Obrázek 5.5: Formulář pro založení nového uživatele
Třída staví komunikaci se serverem na API javax.naming, vytvořeném pro přístup k adresářovým službám. Výhodou je fakt, že API je součástí JDK, a proto není třeba externí knihovna. Nevýhodou může být velká obecnost, se kterou je API vytvořeno. Abstrahuje od mnohých detailů, což ho dělá nezávislým, ale komplikovanějším pro použití. Konfigurace je načítána při inicializaci z příslušné sekce bezpečně uloženého souboru config.properties. Mezi konfigurační data patří service provider, URL, druh autentizace a referral 4 . Třídu zobrazuje diagram na obrázku 5.7. 5.2.1.2
DBAccessPoint
Přístupový bod, sloužící jako rozhraní pro komunikaci s dedikovaným datovým úložištěm, jehož roli zastává databáze Oracle. Na tomto systému jako jediném pozorujeme existenční závislost. Není-li licenční server tento přístupový bod schopen správně inicializovat, tak ani webová služba, ani webová aplikace licenčního serveru nebudou inicializovány. Důvod je zřejmý, aplikace do databáze ukládá velké množství dat, které následně potřebuje používat. Bez nich ztrácí schopnost poskytování licencí, offline autentizace uživatelů, logování událostí, atd. Aplikace sama závisí na takzvaných “třídách Modelu”. Jde o POJO třídy, používané aplikací, které mají schopnost persistence. V databázi existují jako řádky v tabulkách a v aplikaci fungují jako klasické Java Beans. Informace, potřebné pro jejich persistenci, aplikace načítá z metadat ve formě anotací, připojených ke třídě a jejím memberům. 4
způsob předávání referencí v rámci serverové farmy
42
KAPITOLA 5. IMPLEMENTACE
Obrázek 5.6: Tabulka s databází uživatelů
DBAccessPoint přímo využívá framework, který funkci persistence přímo zajišťuje. Zvoleným frameworkem je EclipseLink. Na trhu existuje mnoho implementací standardu JPA, který vybírá množinu JSR norem pro objektově-relační mapování5 v kontextu jazyka Java. Při volbě frameworku bylo přihlíženo k vybraným rozdílům vývojáři nejoblíbenějších frameworků, které ukazuje tabulka 5.2. Konfigurace pro framework je uložena v souboru persistence.xml. Mezi důležitá konfigurační data patří příznak zahrnutí nejmenovaných tříd, URL databázového serveru, JDBC driver, DDL strategie a přístupové údaje, pod kterými server do databáze přistupuje. Klíčovým objektem přístupového bodu je instance třídy EntityManager, jejíž volané metody jsou překládány do DQL, DML, DDL a TCL dotazů databázového stroje. Framework je abstraktní a až konfigurace upřesňuje konkrétního výrobce databázového stroje. To představuje velkou výhodu, protože výrobci k implementaci SQL norem v dnešní době přistupují velmi laxně a dohledávání nuancí v syntaxi konkrétních dotazů je pro vývojáře zbytečnou námahou navíc. Licenční server využívá instanci třídy EntityManager především k funcím hledání konkrétních záznamů, ukládání dat a řízení transakcí. Framework celkově je využíván navíc k tvorbě indexů, přejmenování tabulek6 a sloupců, definování primárních klíčů, atd. Fragment třídy zobrazuje diagram na obrázku 5.8. 5 6
zkráceně ORM přejmenování je nutné v případě, kdy název koliduje s klíčovým slovem standardu SQL
43
5.2. BUSINESS LOGIKA
LDAPAccessPoint -
initialContextFactory: String providerURL: String securityAuthentication: String referral: String
+
authenticate(String, String) : boolean
Obrázek 5.7: Třída LDAPAccessPoint
DBAccessPoint -
em: EntityManager
+ + + +
addUser(User) : boolean addLicense(LicenseGeneration) : boolean getUsers() : List<User> addObjectUserGroup(ObjectUserGroup) : boolean
Obrázek 5.8: Fragment třídy DBAccessPoint
5.2.1.3
BaanSQLAccessPoint
Tento přístupový bod je rozhraním pro přístup k zrcadlové databázi systému Baan. Jeho databázový stroj totiž není čistě relační SQL a navíc systém obsahuje kriticky důležitá data společnosti. I to je důvodem, proč zrcadlová databáze definuje pouze materializované pohledy na data, které jsou navíc omezeny pouze na čtení dat, nikoliv na jejich mazání nebo úpravy. Přístupový bod je realizován jako třída, přímo ovládající JDBC driver pro databázový stroj Oracle 10g. Pro pouhé opakované volání dotazů pro vyčtení dat bez výraznější návaznosti na runtime třídy aplikace je nasazení JPA frameworku zbytečným plýtváním zdrojů. API pro dotazování poskytuje interní knihovna JDK - java.sql. Konfigurace je načítána z již zmiňovaného souboru config.properties, konkrétně sekce “Baan SQL mirror”. Permanentní dostupnost mirror databáze není pro funkcionalitu licenčního serveru kriticky důležitá. Aplikace ho využívá pro zjištění dat o hardware a software, dodaném zákazníkům společnosti. Z těchto dat jsou následně generovány licence. Data jsou replikována do dedikovaného datového úložiště a následně využívána. Formou získávání dat je periodické volání dávkových dotazů mimo pracovní dobu. Zde narážíme na zajímavý problém, protože využívání služeb licenčního serveru je plánováno pro uživatele bez striktního omezení na Českou republiku. Celosvětové využití tedy přínáší
44
KAPITOLA 5. IMPLEMENTACE
Vlastnost Dodržování JPA standardu Využití zdrojů Implementace standardu
Toplink Větší Menší Pomalá
EclipseLink Větší Menší Rychlá
Hibernate Menší Větší Rychlá
Tabulka 5.2: Srovnání JPA frameworků otázku, kdy vlastně pracovní doba nastává. Vhodná doba pro intenzivní výpočetní zátěž serveru tedy bude muset být hledána jako perioda statisticky nejmenšího vytížení serveru. Česká republika bude určitě patřit do zóny vyššího vytížení a proto je předpoklad, že výpočty budou probíhat někdy v průběhu české noci. Třídu zobrazuje diagram na obrázku 5.9. BaanSQLAccessPoint -
connection: Connection slaveOrders: List<String> items: List<String>
+ + +
findSubOrders(String) : void findItems(String) : void findUnits(String) : void
Obrázek 5.9: Třída BaanSQLAccessPoint
5.2.2
Pomocné třídy
Pomocné třídy jsou aktuálně tvořeny třídami LicenseBuilder a bezpečnostními funkcemi ve třídě CryptoUtil, která již byla zmíněna na obrázku 4.3. Popis implementace bezpečnostních funkcí je popsán v sekci 5.4. Zde se proto pouze krátce zmíníme o první jmenované třídě. LicenseBuilder. Zodpovědností třídy je generování licencí. Obsahuje mapovací tabulku pro převod uživatelem vybraných cookies na celé jméno, tedy FQCN. Ke své práci využívá data, poskytnutá ze zadávacího formuláře a třídu CryptoUtil, pomocí které především vytváří podpisy licencí.
45
5.3. WEBOVÁ SLUŽBA
5.3
Webová služba
Komponenta webové služby tvoří po webové aplikaci druhou hlavní část licenčního serveru. Úkolem byla nejen implementace serverové strany služby, ale i tvorba knihovny pro klientskou část služby. Knihovna musí být snadno připojitelná k aplikaci DisMon jako modul platformy Netbeans. Serverovou část služby nazýváme LicenseService, klientskou část LicenseClient. Schéma služby LicenseService znázorňuje obrázek 5.10 jako UML diagram komponent.
LicenseServer
DisMon
LicenseClient
LicenseService
tomanon1_22012012.lic tomanon1_22012012.lic
svatoji01_23012012.lic svatoji01_25012012.lic
Obrázek 5.10: Diagram komponent webové služby LicenseService
5.3.1
Úkoly služby
Webová služba v procesu servisního technika vystupuje hned v několika rolích. Aby služba mohla fungovat, tak musí DisMon mít TCP/IP konektivitu směrem k licenčnímu serveru. Zároveň je důležité, aby navázaná linka byla stabilní a měla dostatečnou kapacitu pro přenos licencí. Role služby shruje tabulka 5.3. Role Authenticator FSM License database proxy Secure server
Popis Ověřování identity uživatele klientské aplikace DisMon Udržování stavu spojení s klietem Vydávání licencí na žádost přihlášeného klienta Bezpečnostní funkce (pro zajištění integrity licence aj.) Tabulka 5.3: Role webové služby
UML sekvenční diagram na obrázku 5.11 ukazuje typický průběh komunikace s úspěšnou autentizací, žádostí o seznam licencí, žádostí o jednu konkrétní licenci a následné odhlášení.
46
KAPITOLA 5. IMPLEMENTACE
LicenseClient
LicenseServer
login(tomanon1, secret123, http://ls.apps.skoda.cz) :boolean :true
getLicenseList() :List :1001, 1002, 1005
getLicense(1005) :byte[] :[username] tomanon1 [expires] 22-12-2012 [swproduct] CA123 ...
logout() :true
Obrázek 5.11: Příklad komunikace
5.3.2
Použité technologie
Webové služby jsou dnes již standardizované. To totiž byl nevyhnutelný krok, protože jejich popularita v průběhu let rapidně rostla a implementovalo je velké množství mainstreamových programovacích jazyků a platforem. Programovací jazyk Java nabízí hned několik API pro webové služby. Veškerá tato API jsou postavena na základní myšlence mapování Java tříd do XML schémat a Java objektů do dokumentů, vyhovujícím schématu. První proces nazýváme binding/unbinding a druhý proces marshalling/unmarshalling. Tyto funkce za programátora vykonává překladač. XML jako standardizovaný značkovací jazyk, který je lidsky čitelný a snadno parsovatelný, byl zvolen jako přenosový formát webových služeb. Z dostupných API jazyku Java (JAX-WS, JAXB, JAX-RS, . . . ) jsme zvolili API JAXWS. Technologie JAXB je totiž již překonaná a technologie JAX-RS pracuje s webovými službami typu REST, které nejsou pro implementaci webové služby licenčního serveru vhodné. JAX-WS jako přenosový formát zpráv používá SOAP, který je nadstavbou XML v tom smyslu, že definuje několik povinných a volitelných částí výsledné zprávy. Zpráva jako celek se skládá z obálky (SOAP Envelope), obsahující hlavičku (SOAP Header), tělo (SOAP body) a volitelné přílohy (SOAP Attachments). Protokol SOAP definuje, co která část bude obsahovat. Jednotlivé části už potom jsou standardní XML dokumenty. Webové služby jsou často srovnávány s proprietárními RPC technologiemi, protože defacto fungují na stejné bázi - volání vzdálených metod. Rozdíly jsou ale velice podstatné a je třeba mít je na paměti. Vše shrnuje tabulka 5.4. Největší z výhod je bezesporu standardizace
47
5.3. WEBOVÁ SLUŽBA
a HTTP(S) jako přenosový protokol na portu TCP/80, který firewally organizací a routery service providerů nefiltrují narozdíl o proprietárních protokolů, jejichž komunikační port není well-known. Největší nevýhodou webových služeb je neefektivní zpracování. Potřeba přizpůsobit se všem totiž vždy vede ke kompromisům a naopak tomu není ani v případě webových služeb. Největším zpomalením je zmiňovaná dvojice procesů marshalling/unmarshalling. Funkce Použitelnost Programovací jazyky Použité protokoly Risk rating na firewallech Zpracování
RPC technologie Omezená Většinou jediný Proprietární Vysoký Rychlé
Webové služby Široká Většina Standardizované Nízký Pomalé
Tabulka 5.4: Srovnání RPC technologií a webových služeb Po vytvoření služby je ještě třeba její publikace. Pokud by služba v budoucnu sloužila třetím stranám, které by přicházely s vlastními konzumenty služby, tak by bylo třeba službu registrovat v databázi služeb, takzvané UDDI directory. Do databáze se ukládají nutné údaje jako URL služby a její rozhraní ve formátu WSDL. I tento formát je postaven na značkovacím jazyce XML. Fragment WSDL ukazuje obrázek 5.12.
48
5.3.3
KAPITOLA 5. IMPLEMENTACE
Rozhraní klientské knihovny
Klientská část webové služby je implementována jako knihovna v archivním formátu JAR. Směrem k licenčnímu serveru implementuje rozhraní služby podle WSDL. Směrem k desktopové diagnostické aplikaci poskytuje rozhraní i implementaci, která funguje jako mezivrstva komunikace z DisMonu na server a naopak. Mnohdy jde o pouhé mapování metod v poměru 1:1, ale občas je třeba konverze dat taková, aby vyhověla API JAX-WS. Rozhraní je zobrazeno na obrázku 5.13. getLicenseList. Vrací seznam identifikátorů licencí, které jsou pro právě přihlášeného uživatele dostupné vzhledem k jeho privilegiím. getLicense. Zasílá klientovi konkrétní licenci, kterou si vyžádá. License musí patřit mezi ty, které jsou pro uživatele dostupné. getEncryptedPasswordDigest. Vrací "osolené"heslo uživatele ve formě SHA-512 otistku, který je pro integritu ještě zašifrovaný privátním RSA klíčem ze serveru. login. Přihlašovací metoda, která ověřuje uživatelské údaje proti LDAP databázi. logout. Odhašovací metoda, kterou DisMon dává najevo skutečnost, že se uživatel z aplikace odhlásil. keepalive. Metoda pro testování spojení mezi licenčním serverem a klientem. getLicenseCharacterCount. Vrací počet znaků konkrétní licence, tato funkce je používána pro ověření integrity licence po přenosu. getPublicKeyChecksum. Vrací otisk veřejného klíče. Tímto způsobem klient ověřuje platnost svého veřejného klíče. getActualPublicKey. Zasílá klientovi aktuálně používaný veřejný klíč. getSalt. Přetížená metoda, která v závislosti na parametru vrací náhodný řetězec, který byl zřetězen s heslem nebo licencí před tvorbou jejich otisků. getIterationCount. Přetížená metoda, která v závislosti na parametru vrací počet iterací, který byl použit při vytváření otisku hesla nebo licence.
5.3.4
Řešení problémů
Přenos dat v počítačové síti je velkým zdrojem potenciálních problémů. Síť může být zahlcena, odříznuta, mít malou přenosovou kapacitu, vysokou chybovost, atd. Kromě problému kanálu může dojít i k problémum rozhraní na koncových stanicích nebo k chybě v TCP/IP stacku. Na všechny tyto problémy je třeba pamatovat a na obou stranách je správně identifikovat a pracovat s nimi. Na aplikační úrovni konektivitu testujeme periodicky volanou metodou keepalive a vhodně nastavenými timeouty čekání na odpovědi. Kromě chyb sítě lze ještě narazit na problémy, jako jsou chyby při autentizaci nebo nenalezení konkrétní licence v databázi. V knihovně LicenseClient proto byla vytvořena hierarchie výjímek, které chybové stavy vhodně popisují a diagnostická aplikace na ně může vhodně reagovat. Výjímky popisuje tabulka 5.5. JAX-WS ovšem vlastní výjímky přenášet neumí. Existuje výjímka protokolu SOAPFaultException, která výjímku na serveru obalí a knihovna klienské části webové služby jí potom parsuje a rekonstruuje původní výjímku podle kódového čísla.
5.3. WEBOVÁ SLUŽBA
< d e f i n i t i o n s name=" L i c e n s e S e r v i c e " targetNamespace= " h t t p : //ws . a l p h a . skoda . c z /" xmlns=" h t t p : // xmlsoap . o r g / wsdl /"> <xsd:schema> <x s d : i m p o r t namespace=" h t t p : //ws . a l p h a . skoda . c z / " /> <message name=" g e t L i c e n s e "> <message name=" g e t L i c e n s e R e s p o n s e "> <s e r v i c e name=" L i c e n s e S e r v i c e "> <s o a p : a d d r e s s l o c a t i o n=" h t t p : // l o c a l h o s t : 8 0 8 0 /LS" /> Obrázek 5.12: WSDL webové služby licenčního serveru
49
50
KAPITOLA 5. IMPLEMENTACE
public L i s t g e t L i c e n s e L i s t ( ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public byte [ ] g e t L i c e n s e ( Long i d ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public byte [ ] g e t E n c r y p t e d P a s s w o r d D i g e s t ( ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public Boolean l o g i n ( S t r i n g username , byte [ ] password ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public Boolean l o g o u t ( ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public Boolean k e e p a l i v e ( ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public I n t e g e r g e t L i c e n s e C h a r a c t e r C o u n t ( Long i d ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public byte [ ] getPublicKeyChecksum ( ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public PublicKey g e t A c t u a l P u b l i c K e y ( ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public byte [ ] g e t S a l t ( Long i d ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public byte [ ] g e t S a l t ( S t r i n g l o g i n ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public I n t e g e r g e t I t e r a t i o n C o u n t ( Long i d ) throws L i c e n s e S e r v i c e E x c e p t i o n ; public I n t e g e r g e t I t e r a t i o n C o u n t ( S t r i n g l o g i n ) throws L i c e n s e S e r v i c e E x c e p t i o n ; Obrázek 5.13: Rozhraní knihovny klienta webové služby
51
5.4. BEZPEČNOST
Kód default 100 200 300 N/A
Výjímka LicenseServiceException AuthenticationException LicenseNotFoundException ServerTimeoutException OtherException
Popis Abstrakce, která je předkem všech ostatních výjímek Chyba při autentizaci uživatele Serveru se nepodařilo najít konkrétní licenci Server není k dispozici Jiná než jmenovaná výjímka
Tabulka 5.5: Popis výjímek
5.4
Bezpečnost
Bezpečnost je v licenčním serveru a potažmo v celém novém distribuovaném systému kriticky důležitá. Server využívá především generování otisků a šifrovací algoritmy.
5.4.1
Generování otisků
Licenční server využívá otisky pro dva hlavní účely - uživatelská hesla a vydané licence. Popíšeme nejprve účel hesel. DisMon si po úspěšném přihlášení uživatele k webové službě musí aktualizovat lokálně uložená hesla. To ovšem ze zřejmých bezpečnostních důvodů není realizovatelné zasláním hesla ve formě otevřeného textu sítí. Útoky typu MITM, sniffing nebo traffic mirror/redirect jsou potenciální hrozbou prozrazení hesla. Heslo proto putuje sítí již ve formě otisku, který je navíc zašifrován privátním RSA klíčem serveru. Druhým účelem je ochrana a ověřování integrity vydaných licencí. Tím jsou chráněny proti neoprávněné změně jejich obsahu. V tomto případě je k licenci připojen podpis, který vznikl jako otisk délky licence a jejího obsahu. Tento otisk je následně zašifrován privátním RSA klíčem serveru, což ho chrání při přenosu sítí. K tvorbě otisků je použita hashovací funkce, konkrétně Secure Hash Algorithm. Ta byla poprvé publikována organizací National Institute of Standards and Technology (NIST) jako U.S. Federal Information Processing Standard (FIPS) [8]. Čas prokázal její schopnosti a odolnost, proto byla použita i v licenčním serveru. Existuje několik variant této funkce, jednou z nejbezpečnějších je SHA-512. Často se ale používá i varianta SHA-1. Proto je dobré znát rozdíly o omezení obou funkcí, které ukazuje tabulka 5.6. Nejdůležitějším ukazatelem je délka otisku, která určuje odolnost funkce proti nalezení kolizí 1. a 2. řádu. Interní struktura kompresních funkcí je u obou stejná. Všechy hashovací funkce jsou ale samy o sobě zranitelné pomocí slovníkových útoků a generování vstupů hrubou silou. To je ale způsobeno filosofií hashovacích funkcí a nelze to chápat jako vadu. Je ovšem třeba najít nějaké východisko. Licenční server při hashovaní užívá hned dvou - solení a iterování. Solení zvyšuje především odolnost proti nalezení kolize u hesel. Uživatelé si totiž často volí hesla, která se snadno zapamatují, ale i snadno prozradí pomocí existujících databází slov. I přes bezpečnostní politiku, která bude klást požadavky na délku a obsah hesla, existují takzvané Rainbow tables, které ukazují odvozovací pravidla, která laika při vymýšlení hesel napadnou nejčastěji. Jmenujme například přidání suffixu “123” v případě, že heslo musí obsahovat alespoň jednu číslici. Sůl je pseudonáhodný řetězec znaků, který se spojí se vstupní
52
KAPITOLA 5. IMPLEMENTACE
Vlastnost Délka výsledného otisku [b] Maximální délka vstupní zprávy [b] Velikost bloku [b] Velikost slova [b] Počet rund Bezpečnost [b]
SHA1 160 64 2 −1 512 32 80 80
SHA512 512 128 2 −1 1024 84 80 256
Tabulka 5.6: Porovnání hashovacích funkcí SHA1 a SHA512 informací hashovací funkce a samotný otisk se potom generuje ze zřetězení obou informací. Takový postup vyžaduje uložení soli všude tam, kde bude třeba vytvářet nové otisky pro porovnání s otisky uloženými. Pro generování otisků byl zvolen generátor SecureRandom a délka soli je 20 bytů. “Doporučení pro délku soli je minimálně 16 bytů a maximálně 32 bytů, které doporučují Ferguson & Schneier pro přesmíru opatrné scénáře. Zároveň ale nemá význam použití délky soli delší než je perioda použitého náhodného generátoru čísel.” [1] A protože generátor SecureRandom je založen na funkci SHA-1, která může generovat maximálně 2160 různých otisků, tak byla zvolena délka 20 bytů. I generátor SecureRandom v základních knihovnách Javy je pro naši situaci vhodný. Je totiž navržen pro generování výstupů pro systémy zabezpečení, které potřebují vysokou míru náhodného prvku a velkou periodu. Navíc jeho seed value je vybírána s rovnoměrným rozložením pravděpodobnosti. Cena, kterou za to platí jsou vyšší nároky na procesor. Naopak v ostatních systémech postačí základní generátor Random, který zmíněné vlastnosti postrádá a uplatnění nachází například v Realtime systémech. Kromě solení licenční server využívá iterování. To je další přidanou hodnotou při zabezpečení, protože hashovaní se několiksetkrát až několikatisíckrát opakuje. Tím se složitost dosažení úspěchu zmiňovaných útoků zvyšuje hned o několik dalších řádů. Informace o počtu iterací opět musí mít dostupná všude, kde je třeba otisky počítat. Celý mechanismus hashovací funkce licenčního serveru s použitím tříd knihovny javax.crypto ukazuje obrázek 5.14.
5.4.2
Šifrování
Šifrování tvoří druhou součást procesů nakládání s licencemi a hesly, které jsou detailně popsány v sekci 5.4.5. Model je postaven na asymetrické kryptografii, protože ta zajišťuje snazší škálovatelnost systému a řeší problém prozrazování hesel v původní diagnostické aplikaci. Využívá se vždy dvojice klíčů, z nichž ten privátní vlastní pouze server a veřejný klíč je distribuován spolu s aplikací Dismon. Základní srovnání asymetrické kryptografie proti symetrické uvádí pro připomenutí tabulka 5.7. Šifrovacím systémem licenčního serveru je RSA - časem prověřený algoritmus, založený na modulárním umocňování. Implementaci poskytuje knihovna javax.crypto, která zajišťuje jak generování klíčů dle bezpečnostních zásad, tak samotný proces šifrování a dešifrování zpráv. Privátní klíč je uložen pro klienty v nepřistupné složce licenčního serveru. Implementaci dokládá obrázek 5.14.
53
5.4. BEZPEČNOST
public s t a t i c byte [ ] getHash ( int i , S t r i n g password , byte [ ] s a l t ) { M e s s a g e D i g e s t d i g e s t = M e s s a g e D i g e s t . g e t I n s t a n c e ( "SHA−512" ) ; digest . reset (); d i g e s t . update ( s a l t ) ; byte [ ] i n p u t = d i g e s t . d i g e s t ( password . g e t B y t e s ( "UTF−8" ) ) ; f o r ( int i = 0 ; i < i ; i ++) { digest . reset (); input = d i g e s t . d i g e s t ( input ) ; } return i n p u t ; } public s t a t i c byte [ ] e n c r y p t ( byte [ ] message ) { i f ( r s a C i p h e r == null ) { r s a C i p h e r = Cipher . g e t I n s t a n c e ( "RSA" ) ; } r s a C i p h e r . i n i t ( Cipher .ENCRYPT_MODE, p r i v a t e K e y ) ; byte [ ] c i p h e r T e x t = r s a C i p h e r . d o F i n a l ( message ) ; } Obrázek 5.14: Hashovací a šifrovací funkce licenčního serveru Kryptografie Výpočetní náročnost Distribuce klíče Počet klíčů pro komunikaci s n stranami Autentizace
Symetrická Nižší Obtížná n Těžko realizovatelná
Asymetrická Vyšší Snadná 2 Snadno realizovatelná
Tabulka 5.7: Porovnání asymetrické a symetrické kryptografie Prozrazení privátního klíče je sice velice nepravděpodobným scénářem, ale systém nabízí zadní vrátka i pro něj. Prozrazení privátního klíče by totiž dalo útočníkovi moc k prolomení integrity hesel a licencí, zaslaných licenčním serverem. Útočník by se zároveň mohl vydávat za server a aplikace DisMon by neměla prostředky, kterými by tuto skutečnost zjistila a mohla na ní reagovat. Ochranný mechanismus na straně serveru v případě zjištění skutečnosti prozrazení klíče ale privátní klíč dokáže zneplatnit. Všechny licence, jejichž digitální podpis byl za pomoci klíče vytvořen, jsou vygenerovány znovu s podpisem, který je vytvořen s pomocí nového privátního klíče. Aplikace DisMon prozrazení klíče zjistí porovnáním otisků veřejných klíčů. Rovnost otisků znamená, že dvojice klíčů od posledního přihlášení nebyla změněna. Nerovnost otisků znamená, že je třeba si stáhnout ze serveru nový veřejný klíč a spolu s ním i nově vygenerované licence a zašifrované otisky uživatelských hesel. Webová služba licenčního serveru pro všechny tyto úkony nabízí rozhraní. Proces aplikace DisMon v kontextu ověřování validity klíčů znázorňuje UML Activity diagram na obrázku 5.15.
54
KAPITOLA 5. IMPLEMENTACE
Úspěšné přihlášení k licenčnímu serveru
Stažení otisku veřejného klíče serveru
Stažený otisk stejný jako lokální otisk ? [ANO]
[NE] Zneplatnění lokálního klíče
Stažení veřejného klíče
Stažení licencí a otisků hesel
Obrázek 5.15: Proces ověřování validity klíčů aplikací DisMon
5.4.3
AAA
Tři písmena této zkratky znamenají autentizaci, autorizaci a účtování. Všechy tři blíže představíme v kontextu licenčního serveru. Autentizace. Ověřování identity lze v novém systému najít hned v několika situacích. Těmi nejčastějšími jsou přihlášení DisMonu k webové službě licenčního serveru a přihlášení uživatele prostřednictvím webového rozhraní k webové aplikaci licenčního serveru. V první situaci DisMon od uživatele přijme zadané heslo a v zašifrované formě ho pošle serveru. Ten si je schopen informaci dešifrovat a lokálně heslo uložit. Autentizaci ale provádí až LDAP server, kterého se uživatel dotazuje nepřímo. Licenční server v této situaci hraje tedy roli uživatelova agenta, jak dokládá sekvenční diagram na obrázku 5.16. Druhou situací, kdy je třeba ověřovat identitu, je přístup do webové aplikace licenčního serveru. Zde proces po obdržení hesla z webového prohlížeče probíhá stejně. Licenční server tedy jako agent provede autentizaci proti LDAP serveru. Autentizace je ale třeba i v situaci, kdy licenční server musí přistupovat do databází pomocí uživatelských účtů, které jsou pro tento účel vytvořeny. Hesla jsou v otevřené formě uloženy v konfiguračních souborech serveru
55
5.4. BEZPEČNOST
User
License Server
LDAP server
login(username, encryptedPassword)
bind(username, decryptedPassword)
alt LDAPofflineLogin [LDAPTimeout] localLogin(username, decryptedPassword)
Obrázek 5.16: Proces přihlášení uživatele
v nepřístupných složkách, které chrání webový kontejner. Jde o soubory persistence.xml pro přístup do dedikované databáze licenčního serveru a o soubor config.properties pro přístup do zrcadlové databáze systému Baan ERP. Posledním místem, kde lze autentizaci ve speciální formě najít, jsou licence. Jejich podpis totiž byl vytvořen s pomocí privátního klíče serveru, který zná pouze a jenom licenční server. A tento fakt uživateli garantuje, že komunikuje skutečně s pravým licenčním serverem. V opačném případě může provést aplikace DisMon obranné kroky a se serverem například může přestat komunikovat. Autorizace. S licenčním serverem ve formě webové aplikace i webové služby pracuje mnoho uživatelů. Po ověření jejich identity je třeba dále řídít jejich přístup ke zdrojům aplikace. Autorizace zde je implementována ve formě RBAC. Uživatelé jsou tedy přiřazeni do různých skupin a přístup ke zdrojům aplikace je vázán až k těmto rolím. Práva uživatele se odvíjí od smluvních vztahů, které firma uživatele a SELČ mají uzavřené. Například modul správy uživatelů je natolik citlivou části aplikace, že přístup k ní by měl být umožněn pouze administrátorům SELČ nebo v menší míře poučeným administrátorům zákazníka. Účtování. Přesnějším výrazem v tomto kontextu by bylo logování aktivity, protože využívání služeb licenčního serveru není zpoplatněná služba. Licenční server používá dvojí logování - na úrovni webového kontejneru a na úrovni aplikace. Webový kontejner Apache Tomcat poskytuje prostřednictvím úpravy konfiguračních souborů možnost výběru granularity, se kterou bude vzniklé události zaznamenávat. Tato hlášení jsou ale vztažena k událostem aplikací jako celků (informace o nasazení, zachycené chybové zprávy, . . . ). Webová aplikace licenčního serveru potom definuje vlastní systém pro ukládání hlášení. Databáze obsahuje verzovací atributy a tabulky pro zaznamenávání samotných hlášení.
56
5.4.4
KAPITOLA 5. IMPLEMENTACE
Ochrana před útoky
Jako kriticky důležitý bod nového systému může být licenční server potenciálně vystaven mnohým útokům. Systém je v případě výpadku serveru schopen provést fallback, kdy diagnostická aplikace DisMon je schopna fungovat v offline módu a LDAP server je autonomní intranetovou entitou, na kterou útok zvenčí není proveditelný. Ovšem filosofie offline módu je v překlenutí krátkodobých výpadků. Dlouhodobě je server nepostradatelnou komponentou distribuovaného systému, a proto jeho ochrana a vysoký uptime jsou důležité. Ochrana je prováděna pomocí integrity, blokování přihlášení a utajování zpráv. Server v určitém kontextu také hraje roli útočníka a proto je třeba zajistit, aby jeho roli nemohl převzít nikdo jiný. Integrita. Integrita licence musí být zachována ve dvou situacích, které představují pro útočníka příležitost útoku. Změna obsahu licence by totiž mohla vyvolat neočekávané chování regulátoru a potažmo celého dopravního prostředku. Licence jako prostý textový soubor k takovému napadení svádí. Stačila by totiž pouze vhodná úprava textu licence, která je navíc sítí přenášena v otevřené textové podobě. Útočníkovi na komunikačním kanálu se systém brání digitálním podpisem, který je k licenci připojen a obsažen v sekci [signature]. Tento podpis vznikl s pomocí silné ireversibilní hashovací funkce a privátního klíče serveru. To zajišťuje jak autentizaci serveru, tak integritu přenášených dat v licenci [2]. Útočník tedy při změně obsahu licence není schopen zrekonstruovat digitální podpis tak, aby mu klient uvěřil a licenci ve změněné formě akceptoval. Druhou možností, kde útok lze provést je lokální systém souborů platformy, na které aplikace DisMon funguje. Licence volně leží na disku a je přístupná komukoliv s administrátorskými právy příslušného stroje. Útok ale opět nemůže být úspěšný, protože veřejný klíč serveru při ověřování podpisu útočníka odhalí a DisMon licenci neakceptuje. Obě situace tedy digitální podpis spolu s omezeními, kladenými na možný obsah licence, vyřeší. Blokování přihlášení. Uživatelé jsou různorodí. Stejně různorodé jsou i společnosti, které jsou zákazníky SELČ. Ne všude je tedy bezpečnostní politika aplikována tak, aby uživatelé byli uvědomělí potenciálních rizik. Takovým rizikem jsou i slabá hesla. Ochrana formou solení a iterování otisků poskytuje už velmi dobrou zbraň pro boj s útočníky, kteří využívají znalosti mentality uživatelů systémů a snaží se hrubou silou o úspěšnou autentizaci. Blokování přihlášení tento útok po několika neúspěšných pokusech útočníka odvrací a zároveň chrání server před DoS a DDoS útoky. Vhodné nastavení parametrů navíc umožní uživatelům, kteří byli vyhodnoceni jako false positives, po uplnutí určité doby další pokusy. Utajování zpráv. Při přihlašování diagnostické aplikace DisMon k webové službě licenčního serveru dochází k přenosu hesla sítí. Toto heslo musí být přenášeno v reversibilní podobě, aby ho server mohl zrekonstruovat. Tento omezující požadavek znamená nutnost použití šifrování, které heslo udrží v rekonstruovatelné podobě a zároveň zabrání útočníkovi v přečtení obsahu zprávy. Šifrování je opět asymetrické s použitím RSA algoritmu a šifrovacím klíčem je veřejný klíč serveru, kterým DisMon zajistí skutečnost, že zprávu si přečte pouze zamýšlený příjemce, kterým je licenční server. MITM. Licenční server je do značné míry i sám útočníkem. Dešifrování hesel od klientů před jejich předáváním k autentizaci proti LDAP serveru je nutné proto, aby si licenční server mohl vytvořit lokální otisky hesel, proti kterým bude autentizovat uživatele v případě, že LDAP server je není k dispozici. Tento model fungování ale představuje bezpečnostní riziko
5.4. BEZPEČNOST
57
převzetí role. Prozrazení veřejného klíče a podvrhnutý DNS záznam by stačil k tomu, aby roli útočník převzal a následně snadno četl hesla, které mu uživatelé prostřednitvím aplikace DisMon zasílají. Pravděpodobnost zjištění privátního klíče je ovšem velmi malá.
58
KAPITOLA 5. IMPLEMENTACE
5.4.5
Aplikace bezpečnosti
Nejdůležitějšími aplikacemi bezpečnosti v licenčním serveru jsou transfer licencí a transfer hesel. Rozdíl mezi nimi nemusí být na první pohled patrný a proto je třeba oba procesy detailněji popsat. V popisech je navíc dobře patrná práce s bezpečností v aplikaci. 5.4.5.1
Transfer hesel
Heslo je tajemstvím, které by nemělo nikomu být odhalováno. Hashovací funkce umožňují jeho uložení ve formě otisku, jehož případné získání útočníkem nepředstavuje příliš velkou bezpečnostní hrozbu. Heslo je tedy před přenosem z licenčního serveru do lokálního datového úložiště aplikace DisMon příslušně upraveno a navíc jsou zabezpečeny jeho integrita, skrytí jeho obsahu a nepopiratelnost zroje. Proces offline ověření uživatelského hesla aplikací DisMon ukazuje obrázek 5.17. Tomu však předchází tvorba zprávy na serveru, která heslo aplikaci DisMon doručí. Ta probíhá v následujících krocích: 1. Zašifrování lokálně uloženého SHA-512 otisku hesla šifrou RSA s použitím platného privátního klíče 2. Zaslání vytvořeného šifrového textu aplikaci DisMon 3. Zaslání soli, vstupující do hashovací funkce, aplikaci DisMon 4. Zaslání počtu iterací hashovací funkce aplikaci DisMon
5.4.5.2
Transfer licencí
Licence je textový soubor, jehož obsah není třeba nějakým způsobem skrývat. Útočník tedy může do rukou licenci dostat a číst její obsah. U licence kontrolujeme pouze její integritu před vlastním použitím v aplikaci DisMon. To je zajištěno pomocí digitálního podpisu, který licenční server před vlastním přenosem licence vytváří. Proces ověření digitálního podpisu aplikací DisMon ukazuje obrázek 5.18. Tomu však předchází tvorba zprávy na serveru, která licenci z podpisem aplikaci DisMon doručí. Ta probíhá v následujících krocích: 1. Zřetězení počtu znaků licence s vlastním obsahem licence 2. Vytvoření SHA-512 otistku ze zřetězení za pomoci náhodné soli a počtu iterací 3. Zašifrování otisku šifrou RSA s použitím platného privátního klíče 4. Zaslání vytvořeného šifrového textu aplikaci DisMon 5. Zaslání soli, vstupující do hashovací funkce, aplikaci DisMon 6. Zaslání počtu iterací hashovací funkce aplikaci DisMon
59
5.4. BEZPEČNOST
Načtení lokálně uloženého otisku v zašifrované podobě
Přijetí přihlašovacích údajů uživatele
Načtení lokálně uložené soli
Načtení lokálně uloženého veřejného klíče
Načtení lokálně uloženého počtu iterací Dešifrování zašifrované podoby otisku veřejným klíčem
Tvorba SHA-512 otisku hesla
Otisky stejné ?
[NE]
[ANO]
Přístup uživateli zamítnut
Uživatel úspěšně přihlášen
Obrázek 5.17: Offline přihlášení uživatele do DisMonu
60
KAPITOLA 5. IMPLEMENTACE
Načtení licence
Zjištění počtu znaků licence
Načtení podpisu z licence
Načtení lokálně uložené soli Načtení lokálně uloženého veřejného klíče Načtení lokálně uloženého počtu iterací
Zřetězení počtu znaků licence a jejího obsahu
Dešifrování podpisu
Vytvoření SHA-512 otisku ze zřetězení
Otisky stejné ? [ANO]
[NE] Licence shledána neplatnou
Licence shledána platnou
Obrázek 5.18: Ověření digitálního podpisu licence
Kapitola 6
Nasazení Licenční server zatím funguje převážně v testovacím prostředí a jeho ostrý provoz je hudbou budoucnosti. Plán nasazení ovšem již nyní má reálné rozměry a je tedy možné se bavit na úrovni detailů konkrétních platforem. Celkový náhled na plné nasazení zobrazuje UML Deployment diagram na obrázku 6.1.
«device» Personal Computer
«device» Database Server JDBC
AJAX/HTTPS
«executionEnvironm... Oracle 10g
«executionEnviron... Web Browser WebPage
«device» Server
Baan SQL mirror
«executionEnviron... WebServer LS Database LicenseServer «device» Notebook
«device» LDAP Server
«executionEnviron... JVM
DisMon
«executionEnvironme... Microsoft AD SOAPoverHTTPS
LDAP UserDatabase
Obrázek 6.1: Plně nasazený licenční server Zobrazeny jsou pouze systémy, které přímo souvisí a komunikují s licenčním serverem. Nový distribuovaný systém obsahuje mnohem větší počet systémů, které však s licenčním 61
62
KAPITOLA 6. NASAZENÍ
serverem souvisí nepřímo nebo zatím není jejich komunikace s ním realizována. Celkový pohled na nasazení tedy ukazuje licenční server v kontextu. Ten tvoří dva druhy klientů a jejich typických platforem, LDAP server s databází uživatelských účtů SELČ a databázový server. Licenční server musí umět komunikovat pomocí čtyř komunikačních protokolů, kterými jsou: AJAX/HTTPS. Tímto protokolem licenční server komunikuje s webovým prohlížečem. AJAX dává webové aplikaci dynamiku WEB2.0 aplikací. HTTPS je pro AJAX nosným protokolem a celou komunikaci zároveň zabezpečuje. Pro funkčnost aplikace je důležité, aby ve webovém prohlížeči byl zapnutý JavaScript. Generování zpráv protokolu zajišťuje framework Vaadin, konkrétně jeho klienská strana “Client-side Engine” a serverová strana “Terminal Adapter”. SOAPoverHTTPS. API webových služeb JAX-WS používá pro komunikaci mezi klientem a službou standardizovaný protokol HTTP. Ten ovšem opět hraje pouze roli nosného a zabezpečovacího protokolu pro SOAP zprávy, které obsahují vlastní protokolová data ve formátu XML. JDBC. Protokol, postavený nad transportním protokolem TCP pro komunikaci s databázovými stroji využívá licenční server jak přímým používáním API JDBC driveru, tak nepřímo pomocí JPA frameworku Eclipselink. LDAP. Standardizovaný ISO protokol pro používání adresářových služeb. Zprávy na straně licenčního serveru vytváří přímo Java, konkrétně knihovna javax.naming.
6.1
Licenční server
Centrální entitou z pohledu systému i nasazení je licenční server. Závislost na něm mají klienti webové služby a webové prohlížeče pro přístup k webové aplikaci. Server sám má závislost na dvou relačních databázích a LDAP serveru. Bez LDAP serveru licenční server dokáže omezeně fungovat, bez relačních databází se ale nedokáže obejít. Zejména se svým dedikovaným datovým úložištěm tvoří neoddělitelný organický celek. Detailní fragement na obrázku 6.2 zobrazuje detail komponenty licenčního serveru, tedy defacto build aplikace ve formátu WAR. Z obrázku je patrno hned několik důležitých skutečností. Složka WEB-INF představuje chráněné úložiště pro soubory, ke kterým nesmí mít uživatel webové aplikace skrz svůj webový prohlížeč přístup. Webový kontejner Apache Tomcat si toho je vědom a proto jakýkoliv přístup zvenčí blokuje. V kořenu složky WEB-INF jsou uloženy konfigurační soubory aplikace a přístupových bodů pro LDAP server a Baan SQL mirror databázi. Konfigurační soubor JPA frameworku pro přístup k dedikovanému datovému úložisti licenčního serveru je uložen v podsložce META-INF. WEB-INF dále obsahuje nalinkované knihovny a vlastní třídy aplikace. Těmi nejdůležitějšími jsou LicenseService a LicenseServerApp. LicenseService je spolu s knihovnami serverovou částí webové služby a LicenseServerApp je servletem/controllerem webové aplikace licenčního serveru. Archiv WAR ještě obsahuje složku VAADIN, která obsahuje zdroje, které jsou přímo přístupné uživatelům webové aplikace. Jde například o soubory stylů a obrázky, jejichž stažení si webový prohlížeč vždy sám v HTTP dotazech vyžádá.
63
6.2. KLIENTI
LicenseServer WEB-INF
VAADIN META-INF
Libraries
config.properties images web.xml
persistence.xml
JAR libraries CSS files
Classes
LicenseService
LicenseServerApp
Java classes
favicon
Obrázek 6.2: Detail licenčního serveru v kontextu nasazení
6.2
Klienti
Diagnostické aplikace DisMon jsou klienty z pohledu webové služby licenčního serveru. Jde o Netbeans RCP aplikace, které jsou spustitelné na všech strojích, které mají instalovánu JVM. Nejčastěji tedy půjde o stolní počítače nebo notebooky, které umožňují mobilitu a potřebnou práci v terénu. Konektivita k serveru je v případě mobility realizována nejčastěji přes GSM síť. Klient pro připojení nevyžaduje žádnou speciální konfiguraci, protože ta je již integrována v klientské knihovně webové služby, která je k aplikaci DisMon jako modul připojena. Klienty webové aplikace licenčního serveru jsou webové prohlížeče. Ty jsou, jak známo, obsaženy ve většině dnešních počítačů a proto licenční server nabízí celkově vysokou přístupnost. Optimální fungování webové aplikace ale vyžaduje prohlížeč, implementující správně W3C normy. Detaily obou klientů ukazuje obrázek 6.3. Obrázek detailně zdůrazňuje rozdíly mezi oběma typy klientů licenčního serveru. Klienty totiž spojuje pouze nosný protokol jejich komunikace se serverem - HTTPS. Stroj “Personal computer” v našem kontextu ukazuje příklad klienta webové aplikace. Jádrem klientské strany je webový prohlížeč a webová stránka. Webová stránka totiž obsahuje části frameworků Vaadin/GWT ve formě Javascriptových souborů, XHTML stránek a CSS souborů, které tvoří klientskou stranu frameworku Vaadin a tvoří přímé uživatele. Stroj “Notebook” v našem kontextu ukazuje příklad klienta webové služby. Na něm je spuštěna aplikace DisMon, která obsahuje knihovnu LicenseClient, jež zodpovídá za komunikaci se serverem a odstiňuje od existence problémů sítě a existence serveru. Obraz služby je ve třídě Service a komunikační rozhraní ve třídě Port.
64
KAPITOLA 6. NASAZENÍ
«device» Notebook «device» Personal Computer «executionEnvironment» Operating System
«executionEnvironment» Operating System «executionEnvironment» JVM
«executionEnvironment» Web Browser
DisMon
WebPage DisMon libraries Vaadin Client-side Engine GWT LicenseClient Port
Service
Obrázek 6.3: Klienti licenčního serveru
6.3
Databázové stroje
Licenční server komunikuje se dvěma databázemi. První z nich je SQL mirror databáze ERP systému Baan, obsahující informace o zákaznících a zboží, které jim bylo dodáno. Druhou databází je dedikované datové úložiště licenčního serveru, které obsahuje lokální kopie vybraných dat ze systému Baan, otisky uživatelských hesel z databáze LDAP serveru a vlastní data, ukládaná licenčním serverem. Obě databáze jsou fyzicky umístěny v intranetu SELČ na jednom relačním databázovém stroji výrobce Oracle [10]. Z pohledu databázového stroje je rozhraní pro přístup z licenčního serveru pro obě databáze stejné. Zajímavostí je ale způsob přístupu z pohledu aplikace licenčního serveru. SQL mirror systému Baan ERP je databáze, kterou využívá více systémů společnosti SELČ. Licenční server nemá právo s daty v ní žádným způsobem manipulovat nebo je měnit. Má však právo data číst, což pro jeho správnou funkci stačí, protože si po přečtení data replikuje do svého dedikovaného datového úložiště. Pro tento Read-Only přístup na úrovni batch dotazů, prováděných mimo business hours je vhodné pouze základní komunikační rozhraní - JDBC driver. V dedikovaném datovém úložišti licenčního serveru ovšem aplikace má právo s daty nakládat libovolně. Komplexita vytvoření takové SQL dotazovací vrsty aplikace by byla velmi vysoká a proto byl pro přístup k této databázi využit JPA framework, který takovouto obecnou dotazovací vrstvu poskytuje a směrem k aplikaci poskytuje Java API, které odstiňuje od low-level komunikace na úrovni SQL dotazů. Framework dotazy ale samozřejmě interně do volání API JDBC driveru překládá, takže z pohledu databází přístup vypadá shodně. Konfigurace přístupu k databázovým strojům obnáší specifikaci hostitelského stroje pomocí IP adresy nebo doménového
6.4. LDAP SERVER
65
jména, číslo TCP portu, jméno služby nebo její identifikátor, uživatelské jméno vytvořeného účtu a příslušné heslo.
6.4
LDAP server
Centrálním úložištěm informací o uživatelských účtech zaměstnanců a zákazníků SELČ je databáze na LDAP serveru. Do značné míry se tedy dá říct, že jde o třetí databázi, se kterou licenční server komunikuje. Pro přesnost je ale třeba připomenout, že jde o jmennou službu, implementující ISO normu X.500. Databáze, kterou LDAP často používá, je takzvaná “Berkley DB”. Jde o vysoce výkonnou databázi pro data typu klíč-hodnota [14]. To je velká odlišnost proti relačním SQL databázím a proto i rozhraní pro přístup k tomuto systému je naprosto odlišné. Zde ale není nutné používat framework, protože Java poskytuje knihovnu javax.naming, řešící právě přístup k adresářovým službám. Konfigurace přístupu k LDAP serveru obnáší specifikaci poskytovatele adresářových služeb, URL, typu autentizace a optimalizační parametry jako jsou timeout a referral.
66
KAPITOLA 6. NASAZENÍ
Kapitola 7
Testování 7.1
Jednotkové testy klientské knihovny
Klientská knihovna webové služby licenčního serveru je nezbytnou součástí aplikace DisMon, přesněji řečeno online módu jejího fungování. V případě, kdy se pomocí mechanismu časovače klient dozví, že server není dostupný, provádí fallback do offline módu. V tom případě je knihovna využívána minimálně, používají se pouze funkce utilit a keepalive zpráv pro testování dostupnosti serveru. V online módu je však klientská knihovna vytížena mnohonásobně víc a aplikace DisMon spoléhá na bezproblémovou komunikaci a správnost dat ze serveru. Server z pohledu aplikace DisMon musí být robustní, musí dodržovat předepsaný protokol a vracet validní data, se kterými je možno dále pracovat. To vše lze nejlépe otestovat pomocí různých vstupních dat knihovny a následnou kontrolou stanovených pravidel pro výstupy. Testovány tedy byly dvě hlavní součásti knihnovny - třída kryptografických utilit a rozhraní se serverem v podobě konzumenta webové služby.
7.1.1
Technologie
Jako vhodný nástroj pro testování funkcionality knihovny se ukázaly být jednotkové (modulové) testy. Analýzou zjištěné požadavky na knihovnu byly následně dekomponovány do několika ucelených tříd a souvisejících metod. A právě testování ucelených celků kódu je hlavní myšlenkou jednotkových testů. Během několika let vývoje se postupně vykrystalizovala rodina takzvaných xUnit frameworků, kterým dal počátek framework SUNIT pro objektový programovací jazyk Smalltalk. Použití frameworků xUnit je dnes zároveň jedním ze základních kamenů jedné z technik vývoje software, takzvaného Test Driven Development. I licenční server využívá pro testování webové služby a knihovny jako celku xUnit framework, konkrétně jUnit. jUnit je psán v jazyce Java, ve kterém se následně definují i konkrétní testy. Existují dvě verze frameworku, starší verze 3 a novější verze 4. Licenční server používá verzi 4, protože oproti svému předchůdci verze 4 poskytuje navíc: • Odstranění návazností na konkrétní třídy • Anotace pro snazší definování speciálních metod 67
68
KAPITOLA 7. TESTOVÁNÍ
• Odstranění mnohých jmenných konvencí • Statické importy takzvaných assertů • Separace testu a testovacích dat Testy knihovny webové služby přímo využívají první čtyři jmenované novinky aktuální verze frameworku. I přes odstranění omezujících konvencí a návazností se vytvořené testy snaží reflektovat třídy a metody knihovny v poměru 1:1. To zvyšuje přehlednost a napomáhá orientaci v kódu.
7.1.2
Výsledky
Kryptografické techniky a algoritmy jsou často náročné jak na čas, tak na výpočetní zdroje. Je tedy vhodné používat prověřené a optimalizované knihovny, které algoritmy implementují. Třída utilit CryptoUtil 1 je díky tomu schopna poskytnout výsledky v reálném čase, což klientská strana aplikace DisMon očekává jak v online, tak v offline módu. Výstupy algoritmů, jakými jsou například otisky z hashovacích funkcí nebo šifrový text šifrovací funkce, mají navíc mnohdy velkou délku, což dělá jejich testování trochu komplikovanějším. Testy třídy CryptoUtil byly implementovány pomocí předpočítaných hodnot otisku a šifrového textu, získaných z testovací zprávy v otevřeném textu. Protože použití asymetrické kryptografie implikuje hned dvojici klíčů, tak šifrové texty byly vytvořeny hned dva, jeden s pomocí privátního RSA klíče a druhý s pomocí veřejného RSA klíče. Pro tvorbu otisku bylo třeba definovat použitou hashovací funkci, počet iterací hashovací funkce a náhodný řetězec, který se jako "sůl"spojí se zprávou před samotným hashováním. Nezávislým výpočtem předpočítané hodnoty potom byly porovnávány s výstupy metod třídy CryptoUtil. Asi nejzajímavějším výsledkem je ověření jedné z málo známých vlastností asymetrické kryptografie, takzvané semantic security. Jde o vlastnost, pozorovatelnou při použití veřejného klíče v šifrovacím režimu. Tento režim se využívá pro posílání tajných zpráv z libovolného počtu stran té jediné straně, která vlastní privátní klíč. Semantic security potom vyžaduje, aby takto získaný šifrový text stejné vstupní zprávy byl vždy odlišný. Této zpočátku méně intuitivní skutečnosti se dosahuje pomocí různého inicializačního vektoru (IV) a její význam tkví ve skrývání skutečnosti, že dva odlišné šifrové texty nesou v otevřeném textu stejnou zprávu. Testování tedy netradičně muselo hlídat, že výsledný šifrový text nebude shodný při vícenásobné aplikaci stejného algoritmu, klíče a zprávy. Knihovna webové služby poskytuje aplikaci DisMon pouze podpůrné funkce pro její činnost. Proto je nutné, aby komunikace s knihovnou probíhala v reálném čase a aplikace DisMon se mohla soustředit na své hlavní úkoly. Testované metody proto v testech mají omezený příděl času a jeho překročení je považováno za selhání, které je nutno odstranit optimalizací metody nebo její kompletní substitucí za výpočetně rychlejší metodu. Obrázek 7.1 prozrazuje, které metody byly časově nejvíce náročnými. Není velkým překvapením, že šlo o metody, pracující nad datovým úložištěm a šifrovací/dešifrovací metody. V metodách, které pracují nad datovým úložištěm je navíc vidět citelný nárůst spotřeby 1
třída se jmenuje stejně jako serverová utilita, ovšem je upravena pro potřeby aplikace DisMon
7.2. TESTOVÁNÍ WEBOVÉHO ROZHRANÍ
69
Obrázek 7.1: Jednotkové testování
času v případě, kdy metody musí prohledat celé datové úložiště ke zjištění výsledku2 . Pomyslné nůžky potřebného výpočetního času takových metod se potom rozevírají úměrně s množstvím dat v úložišti.
7.2
Testování webového rozhraní
Webová aplikace licenčního serveru byla testována zcela odlišným způsobem než knihovna webové služby. Důvody pro použití metody regresního webového testování3 pro webovou aplikaci licenčního serveru jsou hned dva: Naturel webových aplikací. Knihovny, jako například klient webové služby licenčního serveru, neposkytují uživateli aplikace žádné rozhraní (UI). Jediná možnost, jak s nimi interagovat je prostřednictvím jejich API, které používá aplikace, která již v nějaké podobě UI poskytuje. Webové aplikace na druhé straně na grafickém uživatelském rozhraní staví. GUI je standardně tvořeno webovým prohlížečem s renderovacím enginem, který zpracovává zdrojové soubory. Aby tedy byla zachována myšlenka testování z pohledu uživatele, je třeba testovat přímo webové rozhraní prostřednictvím interakcí. Ohled na budoucnost. Aplikace, vytvářené jediným vývojářem mají mnohdy ten problém, že jim plně rozumí pouze a právě on. Potenciální ztráta takového vývojáře má za následek, že spolu s aplikací mnohdy zůstane pouze dokumentace. Ta poskytuje ovšem pouze 2 3
v našem případě šlo o pokus o přihlášení neexistujícího uživatele z angl. regression testing
70
KAPITOLA 7. TESTOVÁNÍ
statický pohled na webovou aplikaci a novým vývojářům i uživatelům dlouho trvá zorientování se v rozhraní. Jde především o správné průchody rozhraním k dosažení určitého cíle, které nová skupina zjišťuje metodou pokus-omyl. Zaznamenání správných průchodů rozhraním a správné odezvy webové aplikace v tu chvíli může ušetřit mnoho nervů i času.
7.2.1
Technologie
Mainstream v automatizovaných webových testech je framework Selenium. Tento framework nabízí nástroje pro plnou automatizaci interakcí s webovou aplikací, které nacházejí uplatnění nejen v oblasti testování. Vývojáři frameworku Vaadin si důležitost testování ve vztahu k úspoře času a nákladů uvědomují a vyvinuli nadstavbu frameworku Selenium TestBench, která ještě lépe zohledňuje specifický charakter webových aplikací vznikajících s použitím frameworku Vaadin. TestBench je postaven na myšlence distribuovaného testovacího modelu, protože testování webových aplikací může být výpočetně náročným procesem. Je totiž mnohdy třeba testovat na úrovni vyhodnocování přibližné shody vstupního a pořízeného multimediálního dokumentu. Aby testování navíc bylo produktivní, testují se různé kombinace operačních systémů a webových prohlížečů, se kterými potenciální uživatelé pracují. Distribuovaný model obsahuje několik komponent: • Recorder (Zaznamenává interakce uživatele s rozhraním) • Library (Poskytuje logiku pro kompilaci interakcí do testů) • Hub (Distribuuje testovací úkoly) • Remote control (Provádí testovací úkoly) Velké nasazení takového testovacího systému potenciálně může zahrnovat hned několik výpočetních uzlů. Pro méně náročné testovací úkony je ale možné celý systém provozovat na jediném výpočetním uzlu. A to je aktuálně i případ licenčního serveru.
7.2.2
Pořizování dat
K získávání dat byl použit Recorder, který je součástí frameworku TestBench. Jde o plugin webového prohlížeče Mozilla Firefox, podobný multimediálním rekordérům a přehrávačům. Po zahájení nahrávání sám zaznamenává akce do testovacího skriptu, který tvoří zároveň scénář průchodu rozhraním. Testovací skript obsahuje trojice (příkaz, cíl, hodnota), které jsou postupně na rozhraní při testování aplikovány. Záznam jednoho ze scénářů je zobrazen na obrázku 7.2. Zaznamenaný scénář je následně pomocí nástrojů knihovny přeložen z markupu zdrojového souboru do Java tříd, aby s ním mohlo posléze být nakládáno ekvivalentně jako s jUnit testy. Několik málo úprav buildovacího souboru a kompilace standardními nástoji docílí spustitelných jUnit testů. Z webové aplikace licenčního serveru byly pořízeny dva jednoduché testovací scénáře. První ověřuje funcionalitu přepínání locale pomocí rozhraní aplikace, které se změnám musí
7.2. TESTOVÁNÍ WEBOVÉHO ROZHRANÍ
71
Obrázek 7.2: Pořizování vstupních dat pro testování
správně přizpůsobovat. Druhý scénář ověřuje funkčnost validace vybraných formulářových dat, kdy neplatný vstup nesmí přijmout a musí uživateli zobrazit správně a kontruktivní chybové hlášení. Scénáře byly zkompilovány do jUnit testů pro kombinaci operačního systému Windows 7 s prohlížečem Mozilla Firefox 12 a Windows 7 s prohlížečem Internet Explorer 9. Výsledkem tedy jsou čtyři třídy, používající framework jUnit, které je možné spouštět při budoucích úpravách zdrojového kódu webové aplikace.
72
KAPITOLA 7. TESTOVÁNÍ
Kapitola 8
Závěr Obecně lze říct, že práce popisuje licenční server víceméně ve všech fázích jeho životního cyklu. Je třeba ale důsledně oddělit práce na webové aplikaci a práce na webové službě, protože procesy jejich vývoje se výrazně lišily. Necelý rok, po který byl server vyvíjen, byla pro webovou aplikaci aplikována kaskádová metodika, kterou je možné přirovnat k Vodopádovému modelu1 . Na druhou stranu vývoj webové služby a příslušné klientské knihovny pro komunikaci s webovou službou probíhal iterativně a inkrementálně. I přes odlišnost metodik nebyl ale vývoj obou komponent nezávislý a prolínání je ve výsledném kódu komponent pozorovatelné například na úrovni využívání sdílených objektů a dat. Vývoj webové aplikace začal poznáváním domény dopravního strojírenství a postupným zužováním této domény až do kontextu modelu fungování společnosti ŠKODA ELECTRIC, jejím návaznostem na sesterské společnosti a dodavatelsko-odběratelské vazby. Toto poznání produkovalo zároveň první rysy objektů, se kterými aplikace nakládá. Ty dávaly první zárodky datového modelu, jehož konstrukce je velkou paralelou celého vývoje2 . Pochopení vize budoucího systému odstartovalo sběr jednotlivých požadavků na hlavní funkční celky licenčního serveru jako aplikace, modelování procesů v organizaci a analytickou činnost celkově. Již předem byla vybrána technologie pro vrstvu webového rozhraní licenčního serveru - framework Vaadin. Současně s analytickými pracemi probíhalo studium framework Vaadin a první experimenty s webovým serverem. Fáze návrhu byla možná tou vůbec nejdůležitější etapou vývoje. Současných i budoucích požavků na licenční server bylo mnoho a především architekturu bylo nutné vystavět v souladu s nimi. V procesu návrhu bylo hojně využíváno návrhových vzorů a jejich dobrých vlastností. Současně s návrhem byly implementovány prototypy rozhraní k externím informačním systémům a testovací aplikace, které rozhraní využívají a potvrzují proveditelnost některých teoretických konceptů, plynoucích z analýzy. Samotnou implementaci licenčního serveru lze rozdělit na implementaci frontendu a backendu. Základ frontendu položily experimenty s frameworkem Vaadin a inspirace již hotovými projekty, veřejně dostupnými na webu. Základem backendu byla rozhraní externích informačních systemů. Implementace postupně začala převádět navrženou aplikaci do reálné funkcionality, ovládané uživateli pomocí rozhraní. Hlavní důraz byl kladen na tvorbu 1 2
z angl. Waterfall model čítač verzí datového modelu se zastavil na hodnotě 13
73
74
KAPITOLA 8. ZÁVĚR
modulu správy uživatelů modulů pro komunikaci s externími systémy. Postupně vytvářený kód webové aplikace a webové služby, včetně klientské knihovny, byl průběžně ukládán v distribuovaném verzovacím systému Mercurial. Testování aplikace ověřilo funkčnost hlavních implementovaných komponent licenčního serveru a znovupoužitelné testy byly rovněž uloženy pro případné další budoucí testování. Důležité poznatky z testování a popis implementace testů jsou uvedeny a textu práce.
8.1
Do budoucna
Server je připraven na přidávání dalších rozširujících funkcionalit, které vyplynou z postupného přechodu na nový distribuovaný systém s centrální správou uživatelů. Rozšíření lze očekávat nejen v oblasti týkající se přímo licenčního serveru, ale (byť s využitím existující platformy) i v nových doménách, např. vyhodnocování použitelnosti desktopové aplikace (UI Gesture Collector), sledování životního cyklu elektronických řídicích jednotek apod. Dokumentace API a návod ke konfiguraci aplikace a serveru umožňují hladké návazání v pracích na právě dokončený vývoj. Jeho nazávislost na operačních systémech, browserech, plná lokalizace do dvou světových jazyků a dvě rozhraní pro práci se serverem skýtají vysokou použitelnost a rozšiřují oblast potenciálních uživatelů, kteří server budou používat. Opomenuta nesmí zůstat ani bezpečnostní stránka aplikace, které byl po celou dobu vývoje přikládán velký význam. Výběr silných metod pro skrývání informací, zachování integrity a ověřování identit a práv prodlužuje potenciální životnost aplikace, protože technický pokrok zatím není ani výhledově ve fázi, kdy by narušení takto postavené bezpečnosti hrubou silou nebo s pomocí heuristik bylo proveditelné.
Literatura [1] Coffey, N.: Password-based encryption in java: salt and key derivation. 2011. http://www.javamex.com/tutorials/cryptography/pbe_salt.shtml, stav 2. 4. 2012.
z
[2] Dostálek, L., M. Vohnoutová a M. Knotek: Velký průvodce infrastrukturou PKI a technologií elektronického podpisu. strany 29–30, 2009. [cit. 25.12.2011]. ISBN 80-247-0469-2. [3] Flígl, S.: EY0XXXXP .15. 2011. Interní dokument SELČ, citováno 17. 4. 2012. [4] Fränkel, N.: Learning Vaadin. strany 52–58, 2011. [cit. 23.1.2012]. ISBN 978-1-84951522-1. [5] Grönroos, M.: Book of Vaadin: 4th Edition. strany 3–4, 2011. [cit. 19.1.2012]. ISBN 978-952-92-6754-5. [6] Kameníček, P.: Dopravní strojírenství a městská hromadná doprava. strany 7–11, 2011. [cit. 26.3.2012]. [7] Keith, M. a M. Schincariol: Pro EJB 3 Java Persistence API. strany 5–6, 2006. [cit. 23.1.2012]. ISBN 978-1-59059-645-6. [8] Lórencz, R.: Slides k předmětu Y36BEZ - přednáška č.5. 2004. http://service.felk.cvut.cz/courses/Y36BEZ/prednasky/bez5.pdf, 2. 4. 2012.
stav
z
[9] Dopravní podnik hlavního města Prahy. http://http://www.dpp.cz/, stav z 17. 4. 2012. [10] Oracle. http://www.oracle.com/, stav z 26. 3. 2012. [11] Škoda Transportation. http://skoda.cz/, stav z 26. 3. 2012. [12] Vaadin. http://www.vaadin.com/, stav z 2. 1. 2012. [13] Wikipedia - MHD. http://cs.wikipedia.org/wiki/M%C4%9Bstsk%C3%A1_hromadn%C3%A1_doprava, stav z 26. 3. 2012. 75
76
LITERATURA
[14] Zörner, S.: LDAP für Java-Entwickler. strany 81–83, 2007. [cit. 13.1.2012]. ISBN 8085839-09-1.
Příloha A
Seznam použitých zkratek AAA Authentication, Authorization, Accounting AJAX Asynchronous Javascript and XML API Application Programming Interface CPLD Complex Programmable Logic Device CPU Central Processing Unit CRUD Create, Retrieve, Update and Delete CSS Cascading Style Sheets DoS Denial of Service DDL Data Definition Language DDoS Distributed Denial of Service DML Data Manipulation Language DNS Domain Name System DSP Digital Signal Processor DQL Data Query Language EA Enterprise Architect ECU Electronic Control Unit EEPROM Electrically Erasable Programmable Read-Only Memory EIS Enterprise Information System ERP Enterprise Resource Planning FIPS Federal Information Processing Standard 77
78
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
FPGA Field-Programmable Gate Array FSM Finite State Machine FQCN Fully Qualified Class Name GNU Gnu’s Not Unix GRASP General Responsibility Assignment Software Patterns GSM Global System Mobile GUI Graphical User Interface GWT Google Web Toolkit HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol HW Hardware I/O Input/Output ICT Information and Communication Technologies ID Identificator IDE Integrated Development Environment IP Internet Protocol ISO International Standard Organisation IV Initialization Vector J2EE Java 2 Enterprise Edition JAR Java Archive JAX-RS Java API for RESTful Web Services JAX-WS Java API for XML Web Services JAXB Java API for XML Binding JDBC Java Database Connectivity JDK Java Development Kit JPA Java Persistence API JS Javascript JSON Javascript Object Notation
79 JSP Java Server Pages JSR Java Specification Request JVM Java Virtual Machine MITM Man in the Middle LDAP Lightweight Directory Access Protocol MCU Multipoint Control Unit MHD Městská Hromadná Doprava MVC Model, View, Controller NIST National Institute of Standards and Technology OOP Object Oriented Programming ORM Object-Relational Mapping PKI Public Key Infrastructure POJO Plain Old Java Object RIA Rich Internet Application RPC Remote Procedure Call RSA Rivest, Shamir, Adleman RTC Realtime Clock SDK Software Development Kit SELČ ŠKODA ELECTRIC a.s. SHA Secure Hash Algorithm SLA Service Level Agreement SLS Service Level Specification SPOF Single Point Of Failure SOAP Simple Object Access Protocol SQL Structured Query Language SW Software TCL Transaction Control Language TCP Transmission Control Protocol
80
PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK
UDDI Universal Description, Discovery and Integration UID Unique Identification Number UIDL User Interface Definition Language UML Unified Modelling Language URL Uniform Resource Locator URI Uniform Resource Identifier W3C World Wide Web Consortium WAR Web Application Archive WSDL Web Service Definition Language WWW World Wide Web XHTML Extensible Hypertext Markup Language XML Extensible Markup Language
Příloha B
Popis použitých knihoven vaadin-6.7.4. Knihovna poskytuje jádro webového frameworku Vaadin. Framework je komponentově orientovaný a knihovna proto obsahuje množství komponent, použitelných v uživatelském rozhraní a s tím související předpřipravené layouty pro komponenty a styly v podobě dvou grafických témat. Mezi další části v jádru frameworku patří mechanismy pro zachytávání akcí, linkování zdrojů a svazování dat s komponentami. vaadin-testbench-2.4.2. Knihovna, obsahující testovací framework Testbench. Distribuována je současně se vzorovými konfiguračními soubory jednotlivých komponent a dávkovými soubory pro spouštění. ojdbc14. JDBC driver pro přístup k databázovým strojům od výrobce Oracle. Poskytuje základní funkce ovladače a v aplikaci poskytuje low-level přístup k databázi, který je třeba ve fázi ladění a troubleshootingu. eclipselink-2.3.0. Dvě knihovny, tvořící JPA framework Eclipselink. Lze ho využít jako embedded část enteprise kontejnerů nebo jako standalone v desktopových aplikacích. Třídy frameworku jsou potom dle specifikace JSR vidět v aplikaci pod balíčkem javax.persistence. METRO 2.0. Web services stack, který zároveň poskytuje základní API JAXB a JAXWS webových služeb a zároveň zjednodušuje tvorbu jejich tvorbu přístup ke službám. Licenční server využívá jeho serverové API a knihovna klientské aplikace jeho API pro konzumenty. java.util. Nativní knihovna Javy, poskytující utility pro tvorbu aplikací. Licenční server využívá například rozhraní generátoru náhodných čísel Random, třídy, potřebné k lokalizaci aplikace (Locale, Properties, ResourceBundle) a datové struktury Stack a HashMap. java.io. Knihovna pro vstupně-výstupní operace licenčního serveru, jako například ukládání RSA klíču na disk a jejich zpětné načítání, serializace objektů aplikace do posloupnosti bytů nebo čtení konfiguračních souborů a reakce na případné chyby v I/O operacích. java.security. Množina API, nástrojů a implementací bezpečnostních protokolů, mechanismů a algoritmů z oblasti kryptografie, PKI, AAA a zabezpečení komunikace. Server tuto knihovnu potřebuje pro bezpečný generátor náhodných čísel, datové struktury otisku, privátního a veřejného klíče a jejich kódování/dekódování při ukládání na disk nebo do socketu. javax.crypto. Obsahuje třídy a rozhraní pro kryptografické operace jako je šifrování, generování klíčů a vyjednávání o tajném klíči komunikačních stran. Části knihovny jsou často svázané s konkrétním providerem, ale umožňují snadné dopsání vlastních implementací. Je 81
82
PŘÍLOHA B. POPIS POUŽITÝCH KNIHOVEN
úzce provázána s knihovnou java.security a i proto ji licenční server využívá především k šifrování a zpracování při něm vzniklých chyb a problémů. javax.servlet. Framework Vaadin sice řeší obsluhu HTTP požadavků na server svým vlastním servletem, ovšem někdy je třeba tuto abstrakční vrstvu obejít a pracovat přímo na úrovni HTTP požadavků a HTTP odpovědí. Servlet API je využíváno pro vhodné nastavení referencí na aplikační třídu do vlákna tak, aby k ní mohly přistupovat i třídy ostatní. Tento návrh v aplikaci má své opodstatnění. java.sql. Interní API Java JDK pro dotazování SQL databází. Po načtení JDBC driveru je toto API použito pro vytváření dotazů, zpracování výsledků atd. java.math. Matematické funkce ve formě Java API. Licenční server používá některé datové typy jako BigInteger, BigDecimal. javax.naming. Knihovna pro přístup k adresářovým službám. Výhodou je fakt, že API je součástí JDK, a proto není třeba externí knihovna. Nevýhodou může být velká obecnost, se kterou je API vytvořeno. Abstrahuje od mnohých detailů, což ho dělá nezávislým, ale komplikovanějším pro použití.
Příloha C
Externí související systémy Baan. Manuálně aktualizovaný ERP systém, ve kterém jsou uloženy všechny zakázky a jejich funkční rozpady na nižší celky. Zodpovědnost za vývoj leží na externí firmě a ICT oddělení - společnosti ŠKODA ICT. Systém zároveň poskytuje rozhraní pro náhled do skladu. Neumožňuje zpětný import do SmarTeamu. DataRail. Systém pro ukládání diagnostických dat, které v případě chyby nebo nestandardního chování regulátoru zasílá přímo vozidlo. Vývojář si zde data vyzvedne a pracuje s nimi. Tento předepsaný způsob ukládání diagnostických dat umožňuje zatím jen malá množina vozidel. EasyArchive. Do systému Baan ukládá data, potřebná pro motorárnu. Existuje jeden klíčový uživatel, který systém obsluhuje. Systém dále pracuje s pohledy, jako jsou například číselníky Baanu atd. Issue tracking. Aplikace pro ukládání bugů a defektů aplikací. Slouží pro centralizaci sběru těchto důležitých informací. LDAP. Databáze uživatelů a zákazníků společnosti ŠKODA. Přístupná je pouze z intranetu a poskytuje autentizační službu a další údaje o uživatelích, jako jsou například kontaktní informace nebo informace o bydlišti. Oracle DB. Jedno z datových úložisť společnosti ŠKODA ELECTRIC. Aplikacím, které potřebují pro svou funkci uložiště pro data, lokální ICT oddělení vytváří izolované materializované pohledy. TeleRail. Systém pro ukládání diagnostických dat, které v případě chyby nebo nestandardního chování regulátoru zasílá přímo vozidlo. Vývojář si zde data vyzvedne a pracuje s nimi. Tento předepsaný způsob ukládání diagnostických dat umožňuje zatím jen malá množina vozidel. SmarTeam. ERP systém, sloužící pro technický úsek společnosti ŠKODA Trasportation. Obsahuje informace o zákaznících a zakázkách společnosti. Pracuje s pohledy na data, exportovanými z hlavního systému Baan.
83
84
PŘÍLOHA C. EXTERNÍ SOUVISEJÍCÍ SYSTÉMY
Příloha D
Konfigurace aplikace a serveru D.1
Deployment aplikace
Nejprve je třeba nastartovat webový kontejner1 : \$ sudo / e t c / i n i t . d/ tomcat6 s t a r t Kontejner Apache Tomcat spravuje aplikace v adresáři $CATALINA_HOME/webapps. Sem stačí webovou aplikaci ve formě archivu WAR nebo jako adresář nahrát. Webový kontejner sám periodicky kontroluje adresář webapps a o skutečnosti, kdy se aplikace dostane pod jeho správu a on pro ní vytvoří kontextovou část URL, informuje následující zprávou: \$ t a i l −f \$CATALINA_HOME/ l o g s / c a t a l i n a . out Deployment i s i n p r o g r e s s . . . d e p l o y ? c o n f i g= f i l e OK − Deployed a p p l i c a t i o n a t c o n t e x t path / L i c e n s e S e r v e r Start i s in progress . . . s t a r t ? path=/ L i c e n s e S e r v e r OK − S t a r t e d a p p l i c a t i o n a t c o n t e x t path / L i c e n s e S e r v e r
D.2
Nastavení služeb webového kontejneru
Defaultní konfigurace webového kontejneru není pro licenční server vhodná a proto je třeba hned několik úprav. Apache Tomcat rád serializuje sessions uživatelů ve chvíli, kdy se restartuje, aby mohl stav aplikace obnovit. Tato funkce v něm ale není příliš šťastně implementována a klade mnohdy nepřijatelné nároky na kód webové aplikace. Při startu/ukončení/restartu tak často dostáváme chybu NotSerializableException. Je tedy třeba upravit konfiguraci kontejneru tak, aby sessions neserializoval (v souboru $CATALINA_HOME/conf/context.xml odkomentovat uzel Manager. <Manager pathname=" " /> 1
konfigurace je uváděna v prostředí GNU/Linux
85
86
PŘÍLOHA D. KONFIGURACE APLIKACE A SERVERU
Apache Tomcat si občas stěžuje, že nemůže najit JDBC driver - což je zvláštní, protže on sám ho k ničemu nepotřebuje a aplikace ma vlastní knihovny a driver ve své classpath. Občas ale Tomcat tuto výjímku zahlásí a pro jeho spokojenost tedy do složky $CATALINA_HOME/lib/ umístíme JDBC driver (viz. příloha o knihovnách B) Na závěr je třeba server restartovat: \$ sudo / e t c / i n i t . d/ tomcat6 r e s t a r t
D.3
Konfigurace aplikace
Aplikace samotná má konfiguraci v souboru config.properties ve složce /WEB-INF, která není přístupná pro klienty webového serveru. Tento soubor obsahuje především konfigurační údaje pro spojení s externími systémy a aplikace soubor jako takový zpracovává při své incializaci. V terminologii licenčního serveru hovoříme o “konfiguraci přístupových bodů”. Fragment konfiguračního souboru vypadá následovně: # General i n s i d e I n t r a n e t=f a l s e # LDAP i n i t i a l C o n t e x t F a c t o r y=com . sun . j n d i . l d a p . LdapCtxFactory providerURL=l d a p : // skoda . c z : 3 8 9 s e c u r i t y A u t h e n t i c a t i o n=s i m p l e r e f e r r a l=f o l l o w # Baan SQL m i r r o r serverName=srv −baan−db1 . skoda . c z portNumber=1521 s i d=baan . skoda . c z username=BAAN_CA_ELC password =∗∗∗∗∗ Jedinou výjímkou u externích systémů je databáze Oracle. Použití frameworku EclipseLink nás od nutnosti psaní low-level kódu pro vytváření, udržování a ukončování spojení odstiňuje. Framework má vlastní konfigurační soubor a pro základní práci s frameworkem je nejdůležitější sekce properties, která definuje potřebné informace pro spojení s databázovým strojem. Ostatní konfigurace frameworku se většinou už týká konkrétních aplikačních tříd a je prováděna pomocí antací, které umožňují konfigurovat framework kontextově. Nedůležitější sekci konfiguračního souboru persistence.xml uvádí následující fragment XML kódu.
D.3. KONFIGURACE APLIKACE
87
88
PŘÍLOHA D. KONFIGURACE APLIKACE A SERVERU
Příloha E
Obsah přiloženého CD Zdrojové soubory spolu s dalšími náležitostmi jsou uloženy na přiloženém CD. Stromová struktura jeho obsahu vypadá následovně: |-|-| | | | | | | | | | | | | | | |-| | | | | | | | | | |
data_models LicenseClient |-- build |-- dist | ‘-- javadoc | |-- nbproject |-- src | |-- cz.skoda.alpha.security.ws.client | ‘-- META-INF | |-- test | ‘-- cz.skoda.alpha.security.ws.client.test | |-- xml-resources ‘-- build.xml LicenseServer |-- build |-- dist | ‘-- javadoc | |-- nbproject |-- src | |-- conf | |-- cz.skoda.alpha.ls | ‘-- cz.skoda.alpha.ws | |-- test
89
90
| | | | |-|-|--
PŘÍLOHA E. OBSAH PŘILOŽENÉHO CD
| ‘-- cz.skoda.alpha.ls.test | ‘-- build.xml README.TXT srv.eap text |-- figures |-- reference.bib |-- tomanek-ing-thesis-2012.tex ‘-- tomanek-ing-thesis-2012.pdf Popis jednotlivých souborů a adresářů je uveden v tabulce E.1
91
Uzel data_models LicenseClient LicenseClient/build LicenseClient/dist LicenseClient/dist/javadoc LicenseClient/nbproject LicenseClient/src LicenseClient/test LicenseClient/xml-resources LicenseClient/build.xml LicenseServer LicenseServer/build LicenseServer/dist LicenseServer/dist/javadoc LicenseServer/nbproject LicenseServer/src LicenseServer/test LicenseServer/build.xml README.TXT srv.eap text
Popis Všechny průběžně vytvářené datové modely aplikace Root projektu klientské knihovny Build knihovny JAR file s knihovnou Dokumentace knihovny Informace o projektu pro IDE Netbeans Zdrojové kódy knihovny jUnit testy Reference na webovou službu Buildfile pro knihovnu Root projektu webové aplikace a služby Build webové aplikace a služby WAR file s webovou aplikací a službou Dokumentace webové aplikace a služby Informace o projektu pro IDE Netbeans Zdrojové kódy webové aplikace (ls) a služby (ws) Vaadin TestBench testy Buildfile pro webovou aplikaci a službu Popis instalace a obsahu CD Soubor s diagramy aplikace EA Text diplomové práce včetně zdrojů ke kompilaci
Tabulka E.1: Popis souborů a adresářů na přiloženém CD
