Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. aplikací z medicínského prostredí

Z´apadoˇcesk´a univerzita v Plzni Fakulta aplikovan´ych vˇed Katedra informatiky a v´ypoˇcetn´ı techniky

Bakal´ aˇ rsk´ a pr´ ace Vzd´ alen´ a spr´ ava Java aplikac´ı z medic´ınsk´ eho prostred´ı

Plzeˇ n 2014

Lubom´ır PETERA

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem bakal´aˇrskou pr´aci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 29. dubna 2014 Lubom´ır PETERA

Abstract Distant management of medical Java applications This bachelor thesis focuses on management and monitoring of the medial applications developed in Java. The introduction of the theoretical part provides a basic outline of the possibility of application monitoring. This is followed by a summary describing the specific software product - medical software Medical Process Assistant. At the end of the theoretical part there is a synopsis of Java management extensions technology. The practical part of this thesis deals with the description of the software solution, which was designed, implemented and nowadays it is used for monitoring as well as management of the product Medical Process Assistant.

Obsah ´ 1 Uvod 2 Teoretick´ aˇ c´ ast 2.1 Moˇznosti sledov´an´ı Java aplikac´ı . . . 2.2 Medical Process Assistant . . . . . . 2.2.1 Serverov´e aplikace . . . . . . 2.2.2 Klientsk´e aplikace . . . . . . . 2.3 Java management extensions . . . . . 2.3.1 Historie technologie JMX . . 2.3.2 Architektura technologie JMX 2.3.3 MBean server . . . . . . . . . 2.3.4 Agent services . . . . . . . . . 2.3.5 Druhy MBean˚ u . . . . . . . . 2.3.6 Notifikace . . . . . . . . . . .

1

. . . . . . . . . . .

3 Realizaˇ cn´ı ˇ c´ ast 3.1 Implementace na stranˇe JMX serveru . 3.1.1 Vytvoˇren´ı MBean˚ u . . . . . . . 3.1.2 Z´asahy do serverov´ ych aplikac´ı . 3.2 ACTMonitor . . . . . . . . . . . . . . 3.2.1 Nasazen´ı aplikace . . . . . . . . 3.2.2 Pˇrehled aplikace . . . . . . . . . 3.2.3 Strom sluˇzeb . . . . . . . . . . 3.2.4 Editory . . . . . . . . . . . . . 3.2.5 Editory obecn´ ych MBean˚ u . . . 3.2.6 Implementace aplikace . . . . . 3.3 Ovˇeˇrov´an´ı kvality implementace . . . . 3.3.1 Manualn´ı testov´an´ı . . . . . . . 3.3.2 Automatick´e testov´an´ı . . . . . 4 Z´ avˇ er

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . .

3 4 7 8 11 13 13 13 14 15 15 16

. . . . . . . . . . . . .

17 18 20 21 22 23 24 24 25 26 31 32 32 33 35

´ 1 Uvod V dneˇsn´ı dobˇe uˇz neplat´ı, ˇze chce-li ˇclovˇek napsat nˇejak´ y program, mus´ı si nejdˇr´ıve sp´ajet programovatelnou desku, navrhnout programovac´ı jazyk, napsat pˇrekladaˇc a pot´e se m˚ uˇze pustit do programov´an´ı. Typick´a u ´loha modern´ıho program´atora je zaloˇzena na znalosti rozhran´ı dvou vrstev, mezi kter´e p´ıˇse sv˚ uj program. Program´ator obvykle nem´a detailn´ı znalost cel´eho syst´emu. Syst´em jedn´e ˇci v´ıce komunikuj´ıc´ıch aplikac´ı je sloˇzen z nˇekolika stovek takto naprogramovan´ ych u ´sek˚ u. To ovˇsem znamen´a velk´a rizika v pˇr´ıpadˇe program´atorovy chyby. Bohuˇzel bezchybn´ y program je utopick´a myˇslenka a kaˇzd´ y program nˇejak´e chyby obsahuje. Tyto chyby se pak vlivem neznalosti niˇzˇs´ıch vrstev aplikace mohou zvˇetˇsovat do katastrofick´ ych rozmˇer˚ u. Proto je v dneˇsn´ı dobˇe nezbytnou souˇc´ast´ı v´ yvoje softwaru testov´an´ı. Testov´an´ı je n´aroˇcn´ y a zdlouhav´ y proces, kter´ y dok´aˇze odhalit vˇetˇsinu chyb, ale nikdy nedok´aˇze podchytit vˇsechny moˇzn´e probl´emy. Dalˇs´ı u ´skal´ı testov´an´ı je simulace podm´ınek, ve kter´ ych budou aplikace bˇeˇzet v ostr´em provozu. To tak´e nen´ı jednoduch´e, ba je to prakticky nemoˇzn´e (nelze vytvoˇrit pˇresnou kopii produkˇcn´ıho prostˇred´ı pro testovac´ı u ´ˇcely). Aplikace se stˇrednˇe kritickou d˚ uleˇzitost´ı, jakou bezesporu nemocniˇcn´ı informaˇcn´ı syst´em je, mus´ı podporovat jeˇstˇe dalˇs´ı u ´roveˇ n zabezpeˇcen´ı proti programov´ ym chyb´am a tou je moˇznost sledov´an´ı a spr´avy bˇeˇz´ıc´ıch aplikac´ı. Pˇr´ıkladem m˚ uˇze b´ yt sledov´an´ı obsahu vyrovn´avac´ı pamˇeti, nebo nastaven´ı promˇen´ ych bˇehov´eho prostˇred´ı. C´ılem t´eto pr´ace je navrhnout n´astroj pro sledov´an´ı a spr´avu aplikac´ı v r´amci bal´ıku l´ekaˇrsk´ ych aplikac´ı Medical Process Assistant. Medical Process Assistant je distribuovan´ y nemocniˇcn´ı software, kter´ y je pˇrev´aˇznˇe napsan´ y v programovac´ım jazyku Java. Je zaloˇzen na interakci sluˇzeb bˇeˇz´ıc´ıch na serverov´ ych poˇc´ıtaˇc´ıch a klientsk´ ych aplikac´ıch bˇeˇz´ıc´ıch na osobn´ıch poˇc´ıtaˇc´ıch v r´amci nemocniˇcn´ı s´ıtˇe. Syst´em aplikac´ı zaloˇzen´ y na aplikac´ıch bˇeˇz´ıc´ıch ve virtu´aln´ım stroji Javy poskytuje mnoho vestavˇen´ ych moˇznost´ı, jak lze aplikaci sledovat. Napˇr´ıklad nen´ı probl´em vytvoˇrit otisk aktu´alnˇe alokovan´e pamˇeti procesu - takzvan´ y MemoryDump. MemoryDump lze pouˇz´ıt k anal´ yze stavu aplikace. Avˇsak 1

´ Uvod anal´ yza stavu procesu t´ımto zp˚ usobem nen´ı trivi´aln´ı a je znaˇcnˇe zdlouhav´a. Navrˇzen´e ˇreˇsen´ı by tedy mˇelo b´ yt co nejjednoduˇsˇs´ı na pouˇzit´ı. Mˇelo by poskytovat aktu´aln´ı informace o stavu procesu. A mˇelo by dovolit s t´ımto stavem do jist´e m´ıry manipulovat, aby bylo moˇzn´e pˇr´ıpadn´e probl´emy ˇreˇsit. V ide´aln´ım pˇr´ıpadˇe by se mˇelo probl´em˚ um pˇredch´azet. Poˇzadavek na syst´em spr´avy aplikac´ı je, aby byl zaloˇzen na technologii Java management extensions. Technologie Java management extensions je standardn´ı zp˚ usob, kter´ ym lze z´ısk´avat informace o bˇeˇz´ıc´ım virtu´aln´ım stroji Javy a na poˇz´ad´an´ı z vnˇejˇsku virtu´aln´ıho stroje v nˇem spouˇstˇet libovoln´ y, pˇredem definovan´ y k´od.

2

2 Teoretick´a ˇc´ast Prvn´ı ˇca´st t´eto pr´ace je rozdˇelena do tˇr´ı celk˚ u: • Struˇcn´ y pˇrehled moˇznost´ı sledov´an´ı aplikac´ı • Popis softwarov´eho ˇreˇsen´ı Medical Process Assistant • Pˇrehled technologie Java management extensions Java aplikace lze, jako kaˇzd´e jin´e aplikace, sledovat standardn´ımi n´astroji operaˇcn´ıho syst´emu. Avˇsak Java aplikace poskytuj´ı pokroˇcil´e moˇznosti sledov´an´ı a n´asledn´eho spravov´an´ı aplikace a virtu´aln´ıho stroje, na kter´em aplikace bˇeˇz´ı. Medical Process Assistant je softwarov´e ˇreˇsen´ı realizovan´e pˇrev´aˇznˇe v programovac´ım jazyku Java. Tento software je zaloˇzen na interakci mezi klientskou aplikac´ı a serverovou sluˇzbou. Serverov´e sluˇzby odstraˇ nuj´ı nutnost komunikace klientsk´e aplikace pˇr´ımo s datab´az´ı a poskytuj´ı jednotn´e rozhran´ı dat bez ohledu na konkr´etn´ı typ datab´aze. Klientsk´e aplikace syst´emu Medical Process Assistant jsou plnohodnotn´e Java aplikace. D´ıky tomu, ˇze se nejedn´a o webov´e aplikace, kter´e by byly spouˇstˇeny pˇrev´aˇznˇe na stranˇe serveru, ale o aplikace bˇeˇz´ıc´ı pˇrev´aˇznˇe na stranˇe klienta, je moˇzn´e ˇc´ast v´ ypoˇcetn´ıho v´ ykonu vyuˇz´ıt na klientsk´e stranˇe. Vlastn´ı sledov´an´ı a n´asledn´e spravov´an´ı bylo realizov´ano dle specifikace Java technologie Java management extensions. Tato technologie je standardn´ı zp˚ usob sledov´an´ı a spr´avy Java aplikac´ı a jej´ı podstatn´a ˇc´ast je integrov´ana do standardn´ıch knihovnen Javy. Technologie Java management extensions je rozdˇelena do tˇr´ı vrstev, coˇz umoˇzn ˇuje znaˇcnou modularitu a jednoduˇsˇs´ı implementaci konkr´etn´ıho ˇreˇsen´ı. Hlavn´ı stavebn´ı kameny technologie Java management extensions jsou takzvan´e MBeany, kter´ ych existuje nˇekolik druh˚ u. Nejjednoduˇsˇs´ı implementace MBeanu je java tˇr´ıda implementuj´ıc´ı specifick´e rozhran´ı.

3

Teoretick´a ˇc´ast

2.1

Moˇznosti sledov´ an´ı Java aplikac´ı

Moˇ znosti sledov´ an´ı Java aplikac´ı

Java aplikace lze, jako kaˇzd´e norm´aln´ı aplikace bˇeˇz´ıc´ı v operaˇcn´ım syst´emu, sledovat n´astroji tohoto operaˇcn´ıho syst´emu. V r´amci operaˇcn´ıho syst´emu Windows je standardnˇe dod´av´an n´astroj Windows Task Manager, kter´ y lze spustit stiskem kl´aves Ctrl+Shift+Esc. Spuˇstˇen´ y Windows Task Manager m´a pˇrehledn´e prostˇred´ı - viz obr´azek 2.1.

Obr´azek 2.1: Windows Task Manager Informace, kter´e m˚ uˇze poskytnout Windows Task Manager: • Identifikace procesu - proces id (PID) • Velikost alokovan´e pamˇeti • Poˇcet vl´aken procesu • Informace o IO operac´ıch • Poˇcet pˇridˇelen´ ych referenc´ı na soubory • Parametry, se kter´ ymi byl proces spuˇstˇen • Identifikace j´adra procesoru, na kter´em proces bˇeˇz´ı

4

Teoretick´a ˇc´ast

Moˇznosti sledov´ an´ı Java aplikac´ı

Syst´emov´ı spr´avci nab´ız´ı pouze z´akladn´ı obecn´e informace o spuˇstˇen´ ych procesech z pohledu operaˇcn´ıho syst´emu. O spuˇstˇen´e Java aplikaci lze vˇsak z´ıskat daleko v´ıce informac´ı. Pokroˇcil´e moˇznosti sledov´an´ı nab´ız´ı specializovan´ y n´astroj JConsole dod´avan´ y standardnˇe spolu s Java v´ yvoj´aˇrsk´ ym bal´ıkem JDK.

Obr´azek 2.2: JConsole Na obr´azku 2.2 je zobrazen spuˇstˇen´ y program JConsole pˇripojen´ y k Java aplikaci. JConsole pr´avˇe zobrazuje informace o bˇeˇz´ıc´ım virtu´aln´ım stroji Javy. Zobrazen´e informace v JConsoly jsou obs´ahlejˇs´ı neˇz informace syst´emov´eho spr´avce. Nav´ıc obsahuj´ı informace specifick´e pro Java aplikace. Mezi dalˇs´ı informace patˇr´ı napˇr´ıklad: • Verze virtu´aln´ıho stroje • Lokace class soubor˚ u = Class path • Poˇcet vl´aken dle jejich typ˚ u 5

Teoretick´a ˇc´ast

Moˇznosti sledov´ an´ı Java aplikac´ı

• Poˇcet nahran´ ych tˇr´ıd • Velikost alokovan´e pamˇeti a jej´ı rozdˇelen´ı do jednotliv´ ych oblast´ı ych metod pro jednotliv´a vl´akna - Stack trace vl´aken • Pˇrehled volan´ • Detekce uv´ıznut´ı vl´aken - Deadlock N´astroj JConsole dovoluje aplikaci nejen monitorovat, ale tak´e ˇc´asteˇcnˇe spravovat prostˇrednictv´ım technologie Java management extensions. JConsole slouˇz´ı jako standardn´ı Java management extensions klient, a tak dovoluje napˇr´ıklad poˇza´dat bˇeˇz´ıc´ı virtu´aln´ı stroj o spuˇstˇen´ı garbage collectoru. Podobn´ ym n´astrojem pro sledov´an´ı Java aplikac´ı je VisualVM, kter´ y je takt´eˇz dod´av´an v Java v´ yvoj´aˇrsk´em bal´ıku JDK. Z hlediska sledov´an´ı virtu´aln´ıho stroje nab´ız´ı podobn´e moˇznosti jako JConsole. Nav´ıc pˇrid´av´a moˇznost vytvoˇrit otisk alokovan´e pamˇeti programu - Heap dump. A umoˇzn ˇuje prakticky plnohodnotn´e profilov´an´ı aplikace. Prostˇred´ı VisualVM je vidˇet na obr´azku 2.3 .

Obr´azek 2.3: VisualVM

6

Teoretick´a ˇc´ast

2.2

Medical Process Assistant

Medical Process Assistant

Medical Process Assistant (zkr´acenˇe MPA) je softwarov´e ˇreˇsen´ı vyv´ıjen´e rakouskou firmou Systema Human Information Systems GmbH [Sys(2011)]. Jedn´a se o nemocniˇcn´ı informaˇcn´ı software mapuj´ıc´ı medic´ınsk´e procesy s d˚ urazem na modularitu syst´emu a snadn´e pˇrizp˚ usoben´ı jak´emukoliv procesu, kter´ y lze v nemocniˇcn´ım prostˇred´ı mapovat. Mezi procesy, kter´e lze prostˇrednictv´ım MPA mapovat a pl´anovat, patˇr´ı napˇr´ıklad: • Management nemocniˇcn´ıch l˚ uˇzek • Pl´anov´an´ı operac´ı • Spr´ava datab´aze pacient˚ u • Mapov´an´ı n´avˇstˇev pacient˚ u v ordinac´ıch ´kol˚ u na nemocniˇcn´ım oddˇelen´ı • Seznam u V´ yvoj MPA zaˇcal pˇred deseti lety v Rakousku. Z´ahy byl software nasazen a dodnes je instalov´an a pouˇz´ıv´an v nˇekolika stovk´ach nemocnic v nˇekolika zem´ıch. Na v´ yvoji se nyn´ı pod´ıl´ı mezin´arodn´ı distribuovan´ y t´ ym, jehoˇz ˇc´ast ˇ je i v Cesk´e republice. St´ale jsou vyd´av´any nov´e verze, a to jak z´aplaty chyb, tak verze s nov´ ymi funkcemi.

ˇ Obr´azek 2.4: Model Rich client application, zdroj: [TRON´ICEK(2011)]

7

Teoretick´a ˇc´ast

Medical Process Assistant

MPA je distribuovanou aplikac´ı zaloˇzenou na architektuˇre klient server. Dle knihy [Ajay D. Kshemkalyani(2011)] lze MPA zaˇradit mezi tipickou aplikace Rich client application neboli aplikace s plnohodnotn´ ym klientem. Strukturu archetypu popisuje obr´azek 2.4 . Hlavn´ı v´ yhody a nev´ yhody tohoto typu aplikac´ı uveden´e v pˇredn´aˇsce shrnuje tabulka 2.1. Na rozd´ıl od aplikace, kter´a by byla zaloˇzena na modelu Web application (respektive Rich Internet application), je velk´a ˇca´st v´ ypoˇcetn´ıho v´ ykonu potˇrebn´eho k bˇehu aplikace konzumovan´a na stranˇe klienta, a tak je v´ yraznˇe ulehˇceno serverov´emu hardwaru. V´ yhody Nev´ yhody rich UI upgrade interactive UI management offline support* Tabulka 2.1: V´ yhody a nev´ yhody modelu Rich client application Z v´ yhod uveden´ ych v tabulce 2.1 neplat´ı pro MPA offline support, ˇcili moˇznost pracovat s aplikac´ı i bez komunikace se serverem. Tato moˇznost nen´ı v MPA plnohodnotnˇe uplatnˇena. Komunikace se serverov´ ymi sluˇzbami je zapotˇreb´ı po celou dobu bˇehu klientsk´ ych aplikac´ı. Pokud je komunikace se serverovou sluˇzbou pˇreruˇsena napˇr´ıklad z d˚ uvodu s´ıt’ov´ ych probl´em˚ u, nebo restartov´an´ı serverov´e sluˇzby, pˇrech´az´ı klientsk´a aplikace do stavu ˇcek´an´ı na obnoven´ı spojen´ı se serverovou sluˇzbou. Po opˇetovn´em nav´az´an´ı spojen´ı aplikace pˇrejde zpˇet do norm´aln´ıho pracovn´ıho reˇzimu. Klientskou aplikaci nen´ı zapotˇreb´ı restartovat.

2.2.1

Serverov´ e aplikace

Serverov´e aplikace jsou sluˇzby poskytuj´ıc´ı informace klientsk´ ym aplikac´ım. Slouˇz´ı zejm´ena k ukl´ad´an´ı a sd´ılen´ı informac´ı pˇrich´azej´ıc´ıch od klient˚ u. D´ale serverov´e sluˇzby odstiˇ nuj´ı klienty od konkr´etn´ıho u ´loˇziˇstˇe dat. V pˇr´ıpadˇe, ˇze se zmˇen´ı datab´azov´ y program, klientsk´ y program by tuto zmˇenu nemˇel poc´ıtit; sluˇzba poskytuj´ıc´ı informace z datab´azov´eho syst´emu vrac´ı klientovi data ve stejn´e podobˇe bez ohledu na druh datab´aze. Sluˇzby d´ale slouˇz´ı k zachov´an´ı informac´ı a t´ım ulehˇcuj´ı provoz datab´azi. Pokud si nˇekolik klient˚ u poˇz´ad´a o stejn´a data, nen´ı zapotˇreb´ı opakovat dotaz do datab´aze. V´ ysledek prvn´ıho dotazu je uchov´an a je vracen dalˇs´ım klient˚ um. Nen´ı zapotˇreb´ı zatˇeˇzovat datab´azi stejn´ ymi dotazy. Spuˇstˇen´e sluˇzby je vidˇet na obr´azku 2.5. 8

Teoretick´a ˇc´ast

Medical Process Assistant

Obr´azek 2.5: Sluˇzby O spuˇstˇen´ı, monitorov´an´ı bˇehu a zastaven´ı sluˇzeb na serveru se star´a sluˇzba JLaunch. Tato sluˇzba m´a definov´any z´avislosti mezi sluˇzbami a pomoc´ı jednoduch´eho konfiguraˇcn´ıho souboru um´ı spustit sluˇzby v korektn´ım poˇrad´ı. Po spuˇstˇen´ı posledn´ı sluˇzby je d´ale ve sluˇzbˇe JLaunch spuˇstˇeno vl´akno ServiceChecker, kter´e kontroluje, zdali jsou vˇsechny sluˇzby spuˇstˇen´e. Toto vl´akno nekontroluje jejich stav, pouze zdali dan´a sluˇzba bˇeˇz´ı. V pˇr´ıpadˇe, ˇze nˇekter´a sluˇzba z listu sluˇzeb nebˇeˇz´ı, je ihned spuˇstˇena znovu. Dalˇs´ı vl´akno, kter´e se spouˇst´ı po startu vˇsech aplikac´ı je DBChecker. Toto vl´akno kontroluje, zdali je moˇzn´e spojit se s datab´az´ı. Vl´akno pos´ıl´a jednoduch´ y sql dotaz a oˇcek´av´a odpovˇed’. V pˇr´ıpadˇe, ˇze se tato zkouˇska nˇekolikr´at nepovede, pˇrech´az´ı vl´akno do stavu ztr´aty kontaktu s datab´az´ı. Ve stavu ztr´ata kontaktu s datab´az´ı vl´akno postupnˇe poˇz´ad´a vˇsechny sluˇzby o ukon9

Teoretick´a ˇc´ast

Medical Process Assistant

ˇcen´ı. Po obnoven´ı spojen´ı s datab´az´ı vl´akno opˇet spust´ı vˇsechny sluˇzby. Tento postup zamezuje zahlcen´ı datab´aze po jej´ım restartu a pˇredch´az´ı probl´em˚ um s poˇskozen´ ymi sluˇzbami vlivem absence spojen´ı s datab´az´ı. Obˇe vl´akna - ServiceChecker a DBChecker, funguj´ı na b´azi periodick´ ych dotaz˚ u. Periodu dotaz˚ u lze nastavit parametry pˇr´ıkazov´e ˇr´adky sluˇzby JLaunch. Standardn´ı nastaven´ı je v ˇra´du des´ıtek dotaz˚ u za hodinu. Jako jedin´a sluˇzba m´a JLaunch pro tyto vl´akna jednoduch´e gui v podobˇe oken s v´ ypisem ud´alost´ı (prakticky velice podobn´e pˇr´ıkazov´emu ˇra´dku). Ostatn´ı sluˇzby nemaj´ı grafick´e uˇzivatelsk´e rozhran´ı. Prvn´ı sluˇzbou, kterou mus´ı sluˇzba JLaunch spustit, je sluˇzba RMIRegistry. Tato sluˇzba zprostˇredkov´av´a nav´az´an´ı komunikace mezi aplikacemi a je tedy nezbytn´a pro spr´avn´ y bˇeh vˇsech sluˇzeb a klient˚ u. Kaˇzd´ y spuˇstˇen´ y program, tedy vˇsechny sluˇzby i klienti, maj´ı povinnost registrovat se v t´eto sluˇzbˇe. Z´aroveˇ n kaˇzd´ y spuˇstˇen´ y program v´ı, kde m´a hledat sluˇzbu RMIRegistry. Sluˇzba RMIRegistry m´a tedy pˇrehled o adres´ach vˇsech bˇeˇz´ıc´ıch sluˇzeb a klient˚ u. Potˇrebuje-li klient nav´azat komunikaci se sluˇzbou poˇza´d´a sluˇzbu RMIRegistry, aby poskytla adresu dan´e sluˇzby. Klient tedy mus´ı zn´at pouze adresu sluˇzby RMIRegistry a identifikaci sluˇzby, se kterou chce nav´azat spojen´ı. Toto m´a jistˇe nesporn´e v´ yhody, mimo jin´e to umoˇzn ˇuje flexibiln´ı rozloˇzen´ı sluˇzeb a klient˚ u v r´amci s´ıtˇe. Sluˇzba RMIRegistry periodicky kontroluje reference na aplikace a odstran ˇuje neplatn´e reference na nebˇeˇz´ıc´ı aplikace. Tento proces je spouˇstˇen typicky nˇekolikr´at za minutu. Ve skuteˇcnosti vl´akno ServiceChecker sluˇzby JLaunch kontroluje pouze, zdali jsou ve sluˇzbˇe RMIRegistry reference na vˇsechny sledovan´e sluˇzby. Sluˇzba JLaunch je v´ yjimkou v registraci do sluˇzby RMIRegistry. Sluˇzba JLaunch se neregistruje pˇri spuˇstˇen´ı, ale aˇz po startu sluˇzby RMIRegistry. Obvykle druhou spouˇstˇenou sluˇzbou je sluˇzba RepoServer. Tato sluˇzba poskytuje ostatn´ım sluˇzb´am a klient˚ um cel´e Java objekty, kter´e dok´aˇze perzistentnˇe ukl´adat do u ´loˇziˇstˇe zvan´eho Repository. Z hlediska klient˚ u sluˇzby RepoServer je nezbytn´e zaˇz´adat managera managera repository objekt˚ u o poskytnut´ı, respektive vytvoˇren´ı managera repository objekt˚ u a tohoto managera pot´e poˇza´dat o dan´ y Java objekt. Z hlediska sluˇzby RepoServer sluˇzba vrac´ı na dotaz klienta serializovanou instanci Java tˇr´ıdy, kter´a je uloˇzena perzistentnˇe v datab´azi. V Repository jsou uloˇzeny objekty reprezentuj´ıc´ı datab´azovou strukturu tabulek, definice report˚ u, nˇekter´e

10

Teoretick´a ˇc´ast

Medical Process Assistant

vlastnosti (properties) aplikac´ı, definice grafick´eho uˇzivatelsk´eho rozhran´ı klientsk´ ych aplikac´ı a mnoho dalˇs´ıch.

2.2.2

Klientsk´ e aplikace

Klientsk´e aplikace zprostˇredkov´avaj´ı komunikaci mezi serverov´ ymi sluˇzbami a uˇzivateli. Obecnˇe lze rozdˇelit klientk´e aplikace na Working centra a ostatn´ı aplikace. Ostatn´ı klientsk´e aplikace jsou obvykle specifick´e jedno´ uˇcelov´e programy, jako napˇr´ıklad prohl´ıˇzeˇc Repository RepoBrowser, inicializ´ator repository, n´astroj pro spr´avu internacionalizace a jin´e. Mezi ostatn´ı klientsk´e aplikace lze zaˇradit i automatick´e testy, kter´e jsou inicializov´any jako klientsk´e aplikace.

Obr´azek 2.6: DefaultWorkBench s nˇemeck´ ym prostˇred´ım

11

Teoretick´a ˇc´ast

Medical Process Assistant

Working centra jsou klientsk´e aplikace, pro jejichˇz pouˇz´ıv´an´ı je zapotˇreb´ı se pˇrihl´asit vyplnˇen´ım uˇzivatelsk´eho hesla a jm´ena. Po pˇrihl´aˇsen´ı se uˇzivateli naˇcte prostˇred´ı programu dle definice kter´a je uloˇzena v Repository. Mezi z´akladn´ı Working centra patˇr´ı DefaultWorkBench (na obr´azku 2.6). To je z´akladn´ı Working centrum pro pˇrihlaˇsov´an´ı sester a doktor˚ u. Nach´az´ı se zde typicky pracovn´ı prostˇred´ı staniˇcn´ıch sester. Druh´e nejpouˇz´ıvanˇejˇs´ı Working centrum (na obr´azku 2.7) je OperatorWorkingCentrum, kter´e slouˇz´ı zejm´ena ke spr´avˇe cel´eho syst´emu, vytv´aˇren´ı definic proces˚ u, spravov´an´ı repository a vytv´aˇren´ı jin´ ych technick´ ych definic.

Obr´azek 2.7: OperatorWorkingCentrum s nˇemeck´ ym prostˇred´ım

12

Teoretick´a ˇc´ast

2.3

Java management extensions

Java management extensions

Java management extensions (zkratka JMX) je java technologie, kter´a pˇrid´av´a moˇznost sd´ılet informace o bˇeˇz´ıc´ım virtu´aln´ım stroji java platformy a poskytuje velik´e moˇznosti tento virtu´aln´ı stroj sledovat a z´aroveˇ n i spravovat. Poskytov´an´ı nˇekter´ ych informac´ı je jiˇz implementov´ano ve standardn´ı java knihovnˇe. Poskytov´an´ı dalˇs´ıch specifick´ ych informac´ı si lze doimplementovat. Rovnˇeˇz nˇekter´e z´akladn´ı prostˇredky pro ovl´ad´an´ı ˇcinnosti aplikace jsou jiˇz implementov´any ( napˇr´ıklad poˇza´d´an´ı o spuˇstˇen´ı garbage collector sledovan´eho virtu´aln´ıho stroje ). Lze si doimplementovat libovoln´e dalˇs´ı ovl´adac´ı prvky. Specifikace technologie urˇcuje pouze rozhran´ı pro tvorbu ovl´adac´ıch prvk˚ u a z´aleˇz´ı na implementaci, co bude dˇelat.

2.3.1

Historie technologie JMX

Technologie Java management extensions, byla jako vˇetˇsina Java technologi´ı, vyv´ıjena prostˇrednictv´ım komunitn´ıho procesu Java specifikation request (JSR). Prvn´ı verze, 1.0 , 1.1 a 1.2, byly vyv´ıjeny pod oznaˇcen´ım JSR 3 [Sun(2002)] (fin´aln´ı verze vyd´ana 7. z´aˇr´ı 2000). Verze 2.0 byla vyv´ıjena jako JSR 255. Dle [Sun(2009)] v souˇcasn´e dobˇe vˇsak nen´ı JSR 255 aktivn´ı a nen´ı ani zahrnuto do Javy verze 7 (respektive do openJDK 1.7). Specifikace vzd´alen´eho pˇr´ıstupu k virtu´aln´ımu stroji Javy byla vyv´ıjena jako JSR 160 [Sun(2003)] a fin´aln´ı verze byla vyd´ana 23. ˇr´ıjna 2003. Od Javy verze 5 je JMX souˇc´ast´ı standardn´ı knihovny Javy. Coˇz znamen´a velk´e usnadnˇen´ı pˇri nasazen´ı aplikace do provozu. Nen´ı zapotˇreb´ı instalovat dalˇs´ı knihovny, ale postaˇc´ı standardn´ı instalace Javy.

2.3.2

Architektura technologie JMX

Technologie JMX je zaloˇzena na tˇr´ıvrstv´e architektuˇre. Tato architektura dovoluje jednoduˇsˇs´ı pr´ace s jednotliv´ ymi vrstvami. Z´amˇena implementace v r´amci jedn´e vrstvy ovlivn´ı pouze minim´alnˇe implementaci v sousedn´ı vrstvˇe a prakticky se nedotkne vzd´alen´e vrstvy.

13

Teoretick´a ˇc´ast

Java management extensions

Technologie Java management extensions se dˇel´ı na vrstvy: Instrumentation vrstva Vlastn´ı v´ ykonn´ y k´od, kter´ y lze spouˇstˇet uvnitˇr virtu´aln´ıho stroje. Na t´eto u ´rovni se nach´az´ı spravovateln´e zdroje. V´ıce o tˇechto zdroj´ıch je v kapitol´ach Druhy MBean˚ u a Notifikace. Agent vrstva Vrstva zprostˇredkov´avaj´ıc´ı komunikaci mezi Instrumentation - vnitˇrn´ı vrstvou a vnˇejˇs´ım svˇetem. V´ıce v kapitole Agent Service a MBean server. Distributed management vrstva Klientsk´a vrstva, kter´a sleduje virtu´aln´ı stroj zvnˇejˇsku. Rozm´ıstˇen´ı a spojen´ı vrstev ukazuje obr´azek 2.5 .

Obr´azek 2.8: Architektura technologie JMX, zdroj: [Sun(2002)]

2.3.3

MBean server

MBean server je registr´ator MBean˚ u ve virtu´aln´ım stroji. Nach´az´ı se na u ´rovni Agent vrstvy. Poskytuje informace o registrovan´ ych MBeanech Distributed 14

Teoretick´a ˇc´ast

Java management extensions

management vrstvˇe. MBean server poskytuje vˇzdy pouze informace o JMX rozhran´ı MBean˚ u, nikdy jejich implementaci. MBeany jsou registrov´any s unik´atn´ım jm´enem objektu (object name). Toto jm´eno pot´e pouˇz´ıv´a klient k pˇr´ıstupu k jednotliv´ ym JMX rozhran´ım MBean˚ u.

2.3.4

Agent services

Agent services jsou objekty, kter´e pˇr´ımo operuj´ı s MBeany. Nach´az´ı se v Agent vrstvˇe technologie JMX. Staraj´ı se o spouˇstˇen´ı operac´ı (metod MBean˚ u) a o podobn´e technick´e vˇeci kolem MBean˚ u. Specifikace JMX definuje n´asleduj´ıc´ı Agent services: Dynamic class loading Dovoluje dynamick´e naˇc´ıt´an´ı tˇr´ıd i ze vzd´alen´ ych zdroj˚ u. Monitors Sleduje hodnoty atribut˚ u MBean˚ u a dovoluje informovat objekty o jejich zmˇen´ach. uˇze pracovat na b´azi jednor´azov´eho Timers Poskytuje pl´anovac´ı sluˇzby. M˚ spuˇstˇen´ı, ˇci opakovan´eho - periodick´eho spouˇstˇen´ı. The relation service Dovoluje vytv´aˇret asociace mezi MBeany.

2.3.5

Druhy MBean˚ u

Managed Bean, neboli MBean je java objekt, kter´ y implementuje specifick´e rozhran´ı a slouˇz´ı jako z´akladn´ı k´amen technologie JMX. MBean m˚ uˇze souˇcasnˇe plnit nˇekolik funkc´ı: • Poskytovatel hodnot atribut˚ u • Poskytovatel hodnot atribut˚ u s moˇznost´ı tyto hodnoty mˇenit • Spouˇstˇeˇc operac´ı • Vydavatel notifikac´ı

15

Teoretick´a ˇc´ast

Java management extensions

Kaˇzd´ y takto implementovan´ y a registrovan´ y MBean m˚ uˇze pak poskytovat ˇ MBeany dok´aˇz´ı poskyinformace (sluˇzby) klient˚ um mimo virtu´aln´ı stroj. Cili tovat a nastavovat hodnoty sv´ ych atribut˚ u a spouˇstˇet operace vnˇe virtu´aln´ıho stroje na poˇz´ad´an´ı z vnˇejˇsku virtu´aln´ıho stroje. Dle knihy [Sullins(2002)] existuje nˇekolik druh˚ u MBean˚ u, kter´e se liˇs´ı t´ım, jak jsou vytv´aˇrena jejich JMX rozhran´ı. Standard MBean Nejjednoduˇsˇs´ı druh MBeanu, jehoˇz JMX rozhran´ı tvoˇr´ı jeho veˇrejn´e metody uveden´e v rozhran´ı, kter´e implementuje. Dynamic MBean Tento druh MBean˚ u implementuje specifick´e rozhran´ı. Avˇsak jeho JMX rozhran´ı lze za bˇehu programu mˇenit. Open MBean Dynamic MBean, kter´ y m´a jednoduˇsˇs´ı samodokumentovatelnou implementaci. Model MBean Rovnˇeˇz druh Dynamic MBeanu, kter´ y m´a za u ´kol vytvoˇrit generick´eho pˇredka skupinˇe MBean˚ u.

2.3.6

Notifikace

Oblast Notifikace v technologii JMX je implementac´ı Java ud´alostn´ıho modelu. To znamen´a, ˇze klient implementuj´ıc´ı specifick´e rozhran´ı se m˚ uˇze zaregistrovat jako posluchaˇc zpr´av (notifikac´ı) z MBeanu (MBean serveru), kter´e registraci umoˇzn ˇuje. Po u ´spˇeˇsn´e registraci klient dost´av´a zpr´avy vyd´avan´e MBeany. Pˇri prvn´ıch pokusech s notifikacemi a pl´anovan´ ym rozˇs´ıˇren´ım podporovan´ ych sluˇzeb na aplikaˇcn´ı server JBoss bylo zjiˇstˇeno, ˇze aktu´alnˇe pouˇz´ıvan´a verze serveru JBoss notifikace nepodporuje. Proto bylo od pouˇzit´ı notifikac´ı v ˇreˇsen´ı sledov´an´ı a spravov´an´ı upuˇstˇeno.

16

3 Realizaˇcn´ı ˇc´ast Druh´a ˇc´ast t´eto pr´ace je rozdˇelena do dvou celk˚ u: • Popis implementace na stranˇe serverov´ ych sluˇzeb • Popis vytvoˇren´eho n´astroje pro spravov´an´ı a sledov´an´ı sluˇzeb Pro realizaci sledov´an´ı a spravov´an´ı sluˇzeb v r´amci softwarov´eho ˇreˇsen´ı MPA bylo zapotˇreb´ı upravit st´avaj´ıc´ı implementaci sluˇzeb a navrhnout n´astroj, kter´ y bude poskytovat uˇzivatelsk´e rozhran´ı pro spravov´an´ı a sledov´an´ı. Standardn´ı n´astroj JConsole se uk´azal jako nevyhovuj´ıc´ı. Z hlediska technologie JMX je sluˇzba JMX serverem a n´astroj na spravov´an´ı a sledov´an´ı JMX klientem. V prvn´ı ˇca´sti t´eto kapitoly jsou zm´ınˇeny zmˇeny proveden´e ve st´avaj´ıc´ı implementaci sluˇzeb. Sluˇzby bylo zapotˇreb´ı upravit tak, aby mohly registrovat novˇe vytvoˇren´e MBeany. D´ıky spoleˇcn´e inicializaci sluˇzeb nebylo zapotˇreb´ı zasahovat v´ yraznˇe do implementac´ı kaˇzd´e sluˇzby zvl´aˇst’, zmˇena byla provedena na jedin´em m´ıstˇe. Konkr´etn´ı MBeany, kter´e se registruj´ı, urˇcuje vol´an´ım statick´ ych metod pomocn´e tˇr´ıdy typicky jedna ˇra´dka zdrojov´eho textu. Z´asah do zdrojov´ ych k´od˚ u sluˇzeb je tedy minim´aln´ı. Sloˇzitˇejˇs´ı implementace je pouze u sluˇzeb JLaunch a RMIServer (podrobnosti o t´eto implementaci jsou v kapitole 3.1.1). V druh´e ˇca´sti t´eto kapitoly je pops´ana implementace novˇe vytvoˇren´eho n´astroje s grafick´ ym uˇzivatelsk´ ym rozhran´ım. Tento n´astroj byl pojmenov´an ACTMnoitor. Jedn´a se o program napsan´ y v jazyku Java. Tento n´astroj pˇrehlednˇe zobrazuje stav spuˇstˇen´ ych sluˇzeb. Uˇzivatelsk´e rozhran´ı ACTMonitoru, kter´e je vidˇet na obr´azku 3.1, je tvoˇreno standardn´ım aplikaˇcn´ım oknem. Toto okno obsahuje strom spuˇstˇen´ ych sluˇzeb s barevn´ ym oznaˇcen´ım stavu uzlu. Po kliknut´ı na uzel MBeanu je v prav´e ˇca´sti okna zobrazen editor pro dan´ y uzel. Editor slouˇz´ı k zobrazen´ı informac´ı o rozhran´ı MBeanu a dovoluje spouˇstˇet metody MBeanu. Pod ˇca´st´ı okna urˇcen´eho pro editory se nach´az´ı oblast

17

Realizaˇcn´ı ˇc´ast

Implementace na stranˇe JMX serveru

pro vypisov´an´ı zpr´av. Za zpr´avy jsou povaˇzov´any v´ ysledky vol´an´ı MBean˚ ua informace o bˇehu aplikace ACTMonitor.

3.1

Implementace na stranˇ e JMX serveru

Sluˇzby, programy operaˇcn´ıho syst´emu, jsou naps´any pˇrev´aˇznˇe v programovac´ım jazyku Java. JMX server je ˇc´ast´ı virtu´aln´ıho stroje a jako takov´ y je ˇca´st´ı implementace sluˇzeb. Z´asahy do implementace sluˇzeb bylo moˇzno prov´adˇet pouze v Java zdrojov´ ych k´odech. D´ıky dobr´emu, objektovˇe orientovan´emu modelu je inicializace sluˇzeb prov´adˇena na spoleˇcn´em m´ıstˇe zdrojov´eho k´odu inicializace sluˇzeb. Z´aroveˇ n s inicializac´ı JMX serveru je veˇrejn´e rozhran´ı tohoto serveru registrov´ano do sluˇzby RMIServer. V RMIServeru m´a sluˇzba obvykle dvˇe reference. Jednu ”norm´aln´ı”referenci, kterou vyuˇz´ıvaj´ı ostatn´ı aplikace k pˇr´ıstupu ke zdroj˚ um poskytovan´ ym sluˇzbou. A druhou ”jmx” referenci, kter´a slouˇz´ı k pˇr´ıstupu k registrovan´ ym MBean˚ um sluˇzby. Prozat´ım nen´ı implementov´ana v RMIServeru ˇz´adn´a vazba mezi tˇemito dvˇema referencemi. Toto je pomˇernˇe nepˇr´ıjemn´a vlastnost RMIServeru, kter´a m˚ uˇze v´est k probl´em˚ um, kdy je sluˇzba restartov´ana a jej´ı ”jmx” reference z˚ ustane v RMIServeru, zat´ımco jej´ı ”norm´aln´ı” reference je odstranˇena. Souˇcasn´e ˇreˇsen´ı tohoto probl´emu spol´eh´a na ˇcasovou prodlevu pˇri restartu sluˇzby. Za tuto dobu by mˇelo b´ yt spuˇstˇeno periodick´e kontrolov´an´ı referenc´ı v RMIServeru, kter´e neplatnou referenci vyˇcist´ı. Druh´ ym z´asahem do implementace sluˇzeb bylo pˇrid´an´ı registrace novˇe napsan´ ych MBean˚ u. V neposledn´ı ˇradˇe bylo zapotˇreb´ı implementovat nov´e MBaeny. Jedn´a se o MBeany: • control • logFile watcher • memory watcher • runtime

18

Realizaˇcn´ı ˇc´ast

Implementace na stranˇe JMX serveru

• service tester • thread error handler Tyto MBeany poskytuj´ı funkcionalitu pro sledov´an´ı a spravov´an´ı aplikace, ve kter´e jsou registrov´any.

19

Realizaˇcn´ı ˇc´ast

3.1.1

Implementace na stranˇe JMX serveru

Vytvoˇ ren´ı MBean˚ u

Bylo navrˇzeno a implementov´ano nˇekolik z´akladn´ıch MBean˚ u. Fyzicky byla naps´ana pro kaˇzd´ y MBean tˇr´ıda a jej´ı rozhran´ı se jm´enem tˇr´ıdy a pˇr´ıponou MBean. Mezi novˇe vytvoˇren´e MBeany jsou rozdˇeleny vˇsechny poˇzadavky na sledov´an´ı a spr´avu bˇeˇz´ıc´ı sluˇzby. V tabulce 3.1 je pˇrehled z´akladn´ıch MBean˚ u s jejich poli p˚ usobnosti. N´azev MBeanu control logFile watcher memory watcher runtime service tester thread error handler

Oblasti p˚ usobnosti spouˇstˇen´ı pˇr´ıkaz˚ u spr´ava logov´an´ı ud´alost´ı spr´ava pamˇeti informace o nastaven´ı sluˇzby testov´an´ı, zdali je sluˇzba v korektn´ım stavu poskytov´an´ı informac´ı o spuˇstˇen´ ych vl´aknech

Tabulka 3.1: Pˇrehled z´akladn´ıch MBean˚ u Control MBean je dynamick´ y MBean a je tvoˇren na z´akladˇe instance tˇr´ıdy CommandServer. Tato tˇr´ıda registruje pˇr´ıkazy, kter´e pak lze zad´avat do pˇr´ıkazov´eho ˇr´adku sluˇzby. MBean slouˇz´ı k vyvol´an´ı tˇechto pˇr´ıkaz˚ u bez nutnosti zad´avat pˇr´ıkaz do pˇr´ıkazov´eho ˇra´dku sluˇzby. LogFile watcher je standardn´ı MBean, kter´ y poskytuje informace o logovan´ ych ud´alostech. Tento MBean dovoluje nastavit logov´an´ı ud´alost´ı. Ud´alosti jsou na r˚ uzn´ ych m´ıstech logov´any r˚ uzn´ ymi instancemi tˇr´ıdy Logger. U instanc´ı tˇr´ıdy Logger lze vzd´alenˇe nastavit mnoˇzstv´ı ud´alost´ı, kter´e budou zaznamen´avat dle jejich priority. MBean umoˇzn ˇuje tak´e uloˇzit aktu´aln´ı stav vl´aken do souboru. Runtime MBean poskytuje informace o spuˇstˇen´em virtu´aln´ı stroji a nav´ıc umoˇzn ˇuje zobrazit nastaven´ı MPA aplikace dan´e souborem .properties. Service tester je MBean, pomoc´ı nˇehoˇz sluˇzba testuje stav sv´eho jmx rozhran´ı. Ne´ uspˇeˇsn´ y test se prom´ıt´a do stavu sluˇzby, kter´ y je zobrazov´an v ACTMonitoru. Thread error handler je novˇejˇs´ı MBean, kter´ y slouˇz´ı k testov´an´ı, zda-li nedoˇslo ke stavu zn´am´emu jako deadlock. Zobrazuje i dalˇs´ı informace o vl´aknech bˇeˇz´ıc´ı sluˇzby. 20

Realizaˇcn´ı ˇc´ast

3.1.2

Implementace na stranˇe JMX serveru

Z´ asahy do serverov´ ych aplikac´ı

St´avaj´ıc´ı implementaci sluˇzeb bylo zapotˇreb´ı upravit tak aby pˇri sv´em spuˇstˇen´ı inicializovaly JMX a pot´e registrovaly MBeany do MBean serveru virtu´aln´ıho stroje. Naˇstˇest´ı prakticky kaˇzd´a MPA aplikace pˇri spuˇstˇen´ı vol´a speci´aln´ı inicializaci syst´emu. V r´amci t´eto inicializace se dˇeje napˇr´ıklad: • Nastaven´ı logov´an´ı - zaznamen´av´an´ı ud´alost´ı do souboru. • Vyˇzaduje se pˇrihl´aˇsen´ı pomoc´ı jm´ena a hesla. • Aplikace se registruje v RMIServeru. • Spuˇstˇen´ı vl´akna sleduj´ıc´ı alokovanou pamˇet’ programu. • Spuˇstˇen´ı vl´akna upozorˇ nuj´ıc´ı na vznik Deadlocku. • Inicializace n´arodn´ıho prostˇred´ı. Do st´avaj´ıc´ı implementace inicializace aplikace byla pˇrid´ana i inicializace JMX. Registrov´an´ı MBean˚ u se pak dˇeje po inicializaci syst´emu, a to jednoduch´ ym vol´an´ım statick´ ych metod tˇr´ıdy, kter´e pom´ah´a s registrac´ı MBean˚ u. Z´asahy do zdrojov´ ych soubor˚ u sluˇzeb byly tedy minim´aln´ı. U bˇeˇzn´ ych sluˇzeb byly pˇrid´any jednotky ˇr´adk˚ u k´odu s registrac´ı MBean˚ u. Trochu n´aroˇcnˇejˇs´ı byla registrace control MBeanu, kter´ y je vytv´aˇren z CommandServeru (viz kapitola 3.1). Sloˇzitˇejˇs´ı, atypickou implementaci vyˇzaduje registrace MBean˚ u u sluˇzeb RMIServeru a JLaunch. U sluˇzby RMIServer lze zaregistrovat MBean server (a tedy i MBeany) aˇz po jej´ım pln´em spuˇstˇen´ı. Sluˇzba JLaunch je jedineˇcn´a t´ım, ˇze jako jedin´a sluˇzba, m˚ uˇze b´ yt korektnˇe spuˇstˇena i bez spojen´ı se sluˇzbou RMIServer. Situace, kdy je sluˇzba JLaunch spuˇstˇena a pˇresto nem´a spojen´ı s RMIServem, nast´av´a napˇr´ıklad pˇri moˇznosti ztr´aty spojen´ı s datab´az´ı a n´asledn´eho restartov´an´ı vˇsech sluˇzeb. Po restartov´an´ı sluˇzby RMIServer je nutn´e zaregistrovat opˇet vˇsechny MBeany v podobˇe MBean serveru sluˇzby JLaunch.

21

Realizaˇcn´ı ˇc´ast

3.2

ACTMonitor

ACTMonitor

Aplikace poskytuj´ıc´ı pˇrehled bˇeˇz´ıc´ıch aplikac´ı a moˇznost jejich spr´avy byla pojmenov´ana ACTMonitor. ACT je zkratka technologie Advanced Component Technology, coˇz je technologie spoleˇcnosti Systema spoleˇcn´a pro vˇsechny produkty spoleˇcnosti vyv´ıjen´e spolu s MPA. Monitor pak znaˇc´ı u ´ˇcel aplikace - sledovat bˇeˇz´ıc´ı sluˇzby.

Obr´azek 3.1: ACTMonitor Aplikace je implementov´ana v jazyku Java. Nˇekter´e konfiguraˇcn´ı soubory jsou naps´any v jazyce XML. V pr˚ ubˇehu implementace byl pˇrid´an poˇzadavek na internacionalizovatelnost aplikace. Nyn´ı aplikace podporuje nˇemeck´e, ˇcesk´e a anglick´e jazykov´e prostˇred´ı. ACTMonitor jako jedna z m´ala aplikac´ı v softwarov´em ˇreˇsen´ı MPA m˚ uˇze b´ yt spuˇstˇena a bez vˇetˇs´ıch omezen´ı provozov´ana bez spojen´ı s RMIServerem. Je tomu tak proto, aby bylo moˇzn´e RMIServer z ACTMnonitoru spouˇstˇet a nebylo zapotˇreb´ı ACTMonitor restartovat pˇri restartov´an´ı RMIServeru. 22

Realizaˇcn´ı ˇc´ast

3.2.1

ACTMonitor

Nasazen´ı aplikace

Aplikace ACTMonitor m˚ uˇze bˇeˇzet na jak´emkoliv stroji, kter´ y m´a pˇr´ıstup ke sluˇzbˇe RMIServer. Typicky je ACTMonitor spuˇstˇen na stroji se sluˇzbami a v poˇc´ıtaˇci administr´atora syst´emu.

Obr´azek 3.2: ACTMonitor - model komunikace Model komunikace ACTMonitoru se sluˇzbami je zobrazen na UML diagramu 3.2. ACTMnonitor stejnˇe jako vˇsechny ostatn´ı aplikace v MPA navazuje spojen´ı se sluˇzbami pomoc´ı RMIServeru. Nˇekter´e operace nad sluˇzbami prov´ad´ı pˇr´ımo. Jin´e operace prov´az´ı za pomoci sluˇzby JLaunch. Napˇr´ıklad spouˇstˇen´ı a ukonˇcov´an´ı sluˇzeb je prov´adˇeno z ACTMonitoru pomoc´ı metody control MBeanu sluˇzby JLaunch. Zat´ım co z´ısk´av´an´ı velikosti aktu´alnˇe alokovan´e pamˇeti je prov´adˇeno pˇr´ımo vol´an´ım metody MBEanu sluˇzby. 23

Realizaˇcn´ı ˇc´ast

3.2.2

ACTMonitor

Pˇ rehled aplikace

ACTMonitor m´a standardn´ı grafick´e uˇzivatelsk´e rozhran´ı. Toto rozhran´ı je vidˇet na obr´azku 3.1 . Na nejvyˇsˇs´ı u ´rovni je okno aplikace rozdˇeleno na dva panely. V lev´em panelu je zobrazen strom spuˇstˇen´ ych sluˇzeb. Prav´ y panel je rozdˇelen opˇet na dva panely. Prav´ y horn´ı panel slouˇz´ı k zobrazov´an´ı podrobnost´ı dle volby ve stromu sluˇzeb. Prav´ y doln´ı panel se naz´ yv´a v´ ystupn´ı oblast a jsou sem barevnˇe vypisov´any v´ ystupy vol´an´ı MBean˚ u sluˇzeb a informace o bˇehu ACTMonitoru. Menu aplikace ACTMonitor je rozdˇeleno do dvou oblast´ı: Akce a Volby. Obˇe poloˇzky menu jsou zobrazeny na obr´azku 3.3. Poloˇzka menu Akce nab´ız´ı moˇznost zobrazit soubor se zaznamen´avan´ ymi ud´alostmi, smazat zpr´avy z prav´eho doln´ıho panelu a ukonˇcit aplikaci.

Obr´azek 3.3: ACTMonitor - menu Poloˇzka menu Volby nab´ız´ı moˇznost nastaven´ı automatick´eho obnovov´an´ı aplikace a frekvenci tohoto obnovov´an´ı. Toto nastaven´ı je d˚ uleˇzit´e, protoˇze sledovan´e sluˇzby samovolnˇe nesdˇeluj´ı informace o sv´em bˇehu, ale ACTMonitor si mus´ı ˇza´dat o jejich stav.

3.2.3

Strom sluˇ zeb

Lev´ y panel ACTMonitoru je tvoˇren stromem sluˇzeb. Tento strom je dynamicky vytv´aˇren na z´akladˇe konfigurace sluˇzby JLaunch. Pokud sluˇzba JLaunch nen´ı spuˇstˇena, je zobrazen pouze ˇsedivˇe koˇrenov´ y uzel JLaunch. Velk´ ym pˇr´ınosem t´eto aplikace je grafick´e zn´azornˇen´ı uzl˚ u sluˇzeb a MBean˚ u. Na obr´azku 3.4 jsou zobrazeny r˚ uzn´e stavy sluˇzeb ve stromu. Pokud aplikace nen´ı spuˇstˇena, respektive jej´ı reference nen´ı v RMIRegistry, je uzel zobrazen ˇsedivˇe. Pokud sluˇzba bˇeˇz´ı bez znateln´ ych probl´em˚ u, je uzel sluˇzby zobrazen zelenˇe. 24

Realizaˇcn´ı ˇc´ast

ACTMonitor

Obr´azek 3.4: ACTMonitor - stavy sluˇzeb Existuje nˇekolik ukazatel˚ u probl´em˚ u ve spuˇstˇen´e sluˇzbˇe. Nejˇcastˇeji se jedn´a o logovanou ud´alost na u ´rovni upozornˇen´ı nebo chyba. Dalˇs´ım ukazatelem je napˇr´ıklad velikost voln´e pamˇeti. Pokud nˇekter´ y z tˇechto ukazatel˚ u ukazuje na probl´emy se sluˇzbou (doch´az´ı voln´a pamˇet’, nastala a byla logov´ana neˇcekan´a ud´alost), uzel t´eto sluˇzby zmˇen´ı barvu na oranˇzovou nebo ˇcervenou. Barva vyˇsˇs´ıch uzl˚ u je pak d´ana nejhorˇs´ı barvou podˇr´ızen´ ych uzl˚ u. D´ıky tomu se zjiˇstˇen´ y ˇspatn´ y stav sluˇzby propaguje aˇz do koˇrenov´eho uzlu stromu sluˇzeb ACTMonitoru.

3.2.4

Editory

Po kliknut´ı na uzel MBeanu se v prav´em horn´ım panelu zobraz´ı generick´ y editor. Tento editor slouˇz´ı k zobrazen´ı informac´ı o hodnot´ach atribut˚ u MBeanu, k nastaven´ı hodnot MBeanu a spouˇstˇen´ı metod.

25

Realizaˇcn´ı ˇc´ast

ACTMonitor

Obr´azek 3.5: ACTMonitor - RepoServer control MBean Tyto editory jsou vytv´aˇreny dynamicky na z´akladˇe JMX rozhran´ı dan´eho MBeanu. Dynamick´e vytv´aˇren´ı editor˚ u, je d˚ uleˇzit´a vlastnost, kter´a v pˇr´ıpadˇe zmˇeny JMX rozhran´ı MBeanu pˇredch´az´ı potˇrebˇe mˇenit implementaci editoru pro tento MBean, ale st´avaj´ıc´ı mechanismus s´am vytvoˇr´ı, pˇri kliknut´ı na uzel, editor jin´ y.

3.2.5

Editory obecn´ ych MBean˚ u

Jak jiˇz bylo zm´ınˇeno, vˇsechny bˇeˇzn´e sluˇzby maj´ı registrov´any z´akladn´ı, spoleˇcn´e MBeany. Tato kapitola popisuje moˇznosti pouˇzit´ı obecn´ ych MBean˚ u prostˇrednictv´ım ACTMonitoru. Jsou zde pops´any moˇznosti editoru pro MBeany: control MBean, logFile watcher MBean, runtime MBean a skupinu standardn´ıch MBean˚ u virtu´aln´ıho stroje.

26

Realizaˇcn´ı ˇc´ast

ACTMonitor

Obr´azek 3.6: ACTMonitor - JLaunch control MBean Na obr´azku 3.6 je zobrazen editor control MBeanu sluˇzby JLaunch. Tento editor je tvoˇren dynamicky dle JMX rozhran´ı MBeanu. Protoˇze control MBean je dynamic MBean (viz kapitola 2.3.5), je teoreticky moˇzn´e, ˇze se jeho JMX rozhran´ı m˚ uˇze za bˇehu programu mˇenit. Prakticky je pouze vytv´aˇren dynamicky pˇri spouˇstˇen´ı sluˇzby a pak uˇz se nemˇen´ı. Pˇr´ıkladem takto promˇenn´eho JMX rozhran´ı je rozhran´ı control MBeanu sluˇzby JLaunch. Pˇr´ıkazy Restart a Shutdown jsou pˇrid´av´any pro kaˇzdou sluˇzbu, kter´a je uvedena v konfiguraci sluˇzby JLaunch. Rozhran´ı control MBeanu je specifick´e pro kaˇzdou sluˇzbu, jak je patrn´e z obr´azk˚ u 3.5 a 3.6. I kdyˇz se jedn´a o stejnou tˇr´ıdu MBeanu, ale editory jsou odliˇsn´e. Operace, kter´e lze nyn´ı pohodlnˇe spouˇstˇet kliknut´ım v editoru control MBeanu ACTMonitoru, bylo dˇr´ıve nutn´e spouˇstˇet pˇr´ıkazy v pˇr´ıkazov´em ˇra´dku sluˇzby.

27

Realizaˇcn´ı ˇc´ast

ACTMonitor

Serverov´e sluˇzby bˇeˇz´ı typicky v operaˇcn´ım syst´emu Windows Server. Pˇri testov´an´ı pˇrechodu na novou verzi Windows Server 2008 bylo zjiˇstˇeno, ˇze v tomto operaˇcn´ım syst´emu je mal´a podpora klasick´ ych ”ˇcern´ ych” oken pˇr´ıkazov´eho ˇra´dku. Vzhledem k tomu, ˇze doposud administr´atory Serverov´ ych sluˇzeb nic nenutilo pouˇz´ıvat ACTMonitor nam´ısto pˇr´ıkaz˚ u v pˇr´ıkazov´em ˇr´adku, bylo implementov´ano nastaven´ı, kter´e znemoˇzn´ı zad´av´an´ı pˇr´ıkaz˚ u v pˇr´ıkazov´em ˇra´dku sluˇzby a donut´ı uˇzivatele pouˇz´ıt control MBean v ACTMonitoru.

Obr´azek 3.7: ACTMonitor - JLaunch logfile MBean Dalˇs´ım d˚ uleˇzit´ ym editorem je editor pro logFile watcher MBean. LogFile watcher je MBean poskytuj´ıc´ı informace o z´akladn´ım stavu sluˇzby na z´akladˇe zaznamen´avan´ ych (logovan´ ych) ud´alost´ı. MBean sleduj´ıc´ı alokovanou operaˇcn´ı pamˇet’ sluˇzby se naz´ yv´a memory watcher. Tento MBean umoˇzn ˇuje nastavit hranici, pˇri kter´e je povaˇzov´an pomˇer vyuˇzit´e pamˇeti oproti alokovan´e pamˇeti za kritick´ y. Tento MBean byl ˇcasto vyuˇz´ıv´an pˇri testov´an´ı indikace stavu sluˇzeb. Dovoluje za bˇehu aplikace mˇenit krit´eria, pˇri kter´ ych je pomˇer vyuˇzit´e pamˇeti 28

Realizaˇcn´ı ˇc´ast

ACTMonitor

proti alokovan´e pamˇeti povaˇzov´an za kritick´ y. Je-li zapotˇreb´ı nastavit stav sluˇzby za kritick´ y, a to tak, aby sluˇzba sama tento sv˚ uj stav indikovala a nebyl ohroˇzen jej´ı bˇeh, staˇc´ı nastavit hranici kritick´eho pomˇeru na n´ızkou hodnotu. Napˇr´ıklad hodnota, kdy jiˇz desetinov´e vyuˇzit´ı alokovan´e pamˇeti je kritick´e, spolehlivˇe zmˇen´ı optiky stav sluˇzby.

Obr´azek 3.8: ACTMonitor - runtime MBean Na obr´azku 3.8 je zobrazen stav ACTMonitoru po zavol´an´ı metody showBaseRuntimeProperties. Ve v´ ystupn´ı oblasti je vidˇet ˇcerven´ y v´ ystup vol´an´ı t´eto metody. Metoda showBaseRuntimeProperties je jedna z metod runtime MBeanu. Runtime MBean slouˇz´ı zejm´ena k z´ısk´av´an´ı informac´ı o bˇeˇz´ıc´ım virtu´aln´ım stroji, nav´ıc poskytuje i informace o vlastnostech - properties specifick´ ych pro aplikace bˇeˇz´ıc´ı v r´amci softwarov´eho ˇreˇsen´ı MPA. Ve stromu sluˇzeb je tak´e uzel reprezentovan´ y sloˇzkou s n´azvem jvm. Uzly pod t´ımto uzlem jsou standardn´ı MBeany virtu´aln´ıho stroje. Tyto uzly nejsou barevnˇe oznaˇceny barevn´ ym koleˇckem jako ostatn´ı uzly, m´ısto barevn´eho koleˇcka maj´ı pouze otazn´ık. Tyto uzly se opticky nepod´ıl´ı na stavu sluˇzby. Na obr´azku 3.9 je zobrazen editor pro jeden ze standardn´ıch MBean˚ u virtu´al29

Realizaˇcn´ı ˇc´ast

ACTMonitor

Obr´azek 3.9: ACTMonitor - jvm MBeany n´ıho stroje, a to Runtime MBeanu. Tento MBean pˇrin´aˇs´ı z´akladn´ı informace o spuˇstˇen´em virtu´aln´ım stroji. Kaˇzd´ y uzel sluˇzby tak´e obsahuje uzel LogFile. Po kliknut´ı na tento uzel se zobraz´ı v nov´em oknˇe soubor s uloˇzen´ ymi zaznamen´avan´ ymi ud´alostmi. Pro zobrazen´ı obsahu tohoto souboru bylo pouˇzito existuj´ıc´ı komponenty MPA. Byl vytvoˇren potomek t´eto komponenty, kter´ y dovoluje naˇc´ıst soubor ze vzd´alen´eho um´ıstˇen´ı. Ke ˇcten´ı souboru s ud´alostmi byl pouˇzit logFile watcher MBean, kter´emu bylo pˇrid´ano nˇekolik metod.

30

Realizaˇcn´ı ˇc´ast

3.2.6

ACTMonitor

Implementace aplikace

Aplikace ACTMonitor je naps´ana v programovac´ım jazyku JavaSE 6. V´ yvoj postupnˇe proch´azel verzemi oprav v´ yvoj´aˇrsk´eho bal´ıku JDK a souˇcasnˇe podporovan´a verze je Java SE 6 Update 23. K pˇrekladu zdrojov´ ych k´od˚ u byl pouˇzit n´astroj Maven konkr´etnˇe verze 2. K psan´ı zdrojov´ ych k´od˚ u byl pouˇzit n´astroj Eclipse a to postupnˇe od verze 3.3 aˇz po verzi 3.6. K standardn´ımu sestaven´ı Eclipse byly instalov´any nˇekter´e z´asuvn´e moduly - pluginy. Pluginy pouˇzit´e pˇri v´ yvoji ACTMonitoru: FindBugs Potenci´aln´ı defekty k´odu na u ´rovni pˇreloˇzen´ ych .class soubor˚ u hl´ıd´a FindBugs plugin. Tento plugin pom´ah´a odhalit program´atorsk´e chyby jiˇz pˇri psan´ı zdrojov´eho k´odu v editoru se zapnut´ ym automatick´ ym pˇrekladem. Checkstyle Kontrolu konvenc´ı pˇri psan´ı zdrojov´eho k´odu zabezpeˇcuje Checkstyle plugin. Ten tak´e hl´ıd´a nˇekter´e vlastnosti k´odu, jako je napˇr´ıklad veˇrejn´e atributy tˇr´ıdy, velk´ y poˇcet ˇra´dk˚ u tˇr´ıdy a metody, velk´ y poˇcet argument˚ u metody a mnoho dalˇs´ıch. Nut´ı tedy program´atora vyhnout se tˇemto neˇrestem, kter´e ˇcin´ı zdrojov´ y k´od nepˇrehledn´ y. Maven Tento plugin podporuje pˇreklad zdrojov´ ych k´od˚ u pomoc´ı n´astroje Maven. Pom´ah´a zejm´ena pˇri pˇrekladu projektu, kter´ y pouˇz´ıv´a knihovny tˇret´ıch stran, kter´e jsou sv´az´any s projektem pomoc´ı programov´eho objektov´eho modelu Mavenu. QuantumDB QuantumDB plugin je pouˇz´ıv´an k pˇr´ıstupu do datab´aze prostˇrednictv´ım jazyku SQL. Team Team plugin pˇrin´aˇs´ı podporu verzovac´ıho syst´emu PForce. Aplikace ACTMonitor byla vyv´ıjena v komerˇcn´ım prostˇred´ı. Proces v´ yvoje se musel ˇr´ıdit pravidly spoleˇcnosti, pro kterou byla aplikace vyv´ıjena. Psan´ı programu bylo rozdˇeleno na u ´lohy s odhadem trv´an´ı obvykle do dvou ˇclovˇekodn´ı. Typick´ y proces psan´ı k´odu v r´amci jedn´e t´eto u ´lohy byl rozdˇelen do nˇekolika krok˚ u. Prvn´ı krok byla vˇzdy anal´ yza zad´an´ı. Druh´ ym krokem bylo naps´an´ı vlastn´ıho zdrojov´eho k´odu. Tento zdrojov´ y k´od byl pot´e vloˇzen do verzovac´ıho syst´emu. Do pr˚ uvodn´ıho dokumentu u ´lohy byla zmˇena pops´ana a 31

Realizaˇcn´ı ˇc´ast

Ovˇeˇrov´ an´ı kvality implementace

byly pˇrid´any instrukce pro manu´aln´ı otestov´an´ı. Dalˇs´ım krokem byla kontrola zdrojov´eho k´odu pomoc´ı takzvan´eho code-review. Code-review je zjednoduˇsenˇe ˇreˇceno zkontrolov´an´ı zdrojov´eho k´odu osobou, kter´a k´od nepsala. Code-review bylo prov´adˇeno zkuˇsenˇejˇs´ımi zamˇestnanci spoleˇcnosti. Pokud byly nalezeny defekty k´odu, byl zdrojov´ y k´od vr´acen autorovi na opravu. Po opravˇe byl proces code-review opakov´an. Kdyˇz byl zdrojov´ y k´od vyhovuj´ıc´ı, byl poskytnut zadavateli k softwarov´emu testov´an´ı.

3.3

Ovˇ eˇ rov´ an´ı kvality implementace

Softwarov´ y produkt Medical Process Assistent je vyv´ıjen s d˚ urazem na vysokou kvalitu. Produkt je manu´alnˇe i automaticky testov´an. Testov´an´ı je uzp˚ usoben cel´ y v´ yvojov´ y proces.

3.3.1

Manualn´ı testov´ an´ı

Programy dod´avan´e v r´amci softwarov´eho ˇreˇsen´ı Medical Process Assistent jsou pravidelnˇe manu´alnˇe testov´any zamˇestnanci oddˇelen´ı QA (Quality assurance). Kaˇzd´e sestaven´ı produktu je pˇred instalac´ı k z´akazn´ıkovi testov´ano sadou z´akladn´ıch manu´aln´ıch testu a v´ ybˇerem rozˇsiˇruj´ıc´ıch manu´aln´ıch testu. Manu´aln´ı testy se prov´adˇej´ı dle popisu v dokumentu QS Template. Form´at dokumentu QS Template byl zmˇenˇen v pr˚ ubˇehu implementace. P˚ uvodn´ı dokument obsahoval seznam kroku, kter´e tester musel prov´est, aby ovˇeˇril chov´an´ı programu. Nov´ y form´at dokumentu obsahuje tabulku o dvou sloupc´ıch. V prvn´ım sloupci je uveden popis akce, kterou mus´ı tester prov´est. V druh´em sloupci je oˇcek´avan´ y v´ ysledek akce (slovn´ı popis ci obr´azek). Oba form´aty dokumentu obsahuj´ı pole pro vyplnˇen´ı doplˇ nkov´ ych u ´daj˚ u o manu´aln´ım testu. Do tˇechto pol´ı se zad´av´a napˇr. verze softwaru, od kter´e je moˇzn´e tento test prov´est, motivace k tomuto testu, pˇredpokl´adan´ y ˇcas proveden´ı testu. Dokumenty QS Template jsou sd´ıleny mezi v´ yvoj´aˇri a testeˇri, pˇriˇcemˇz pr´avo vytv´aˇret je a editovat maj´ı obˇe strany. K softwarov´emu ˇreˇsen´ı t´eto pr´ace byly naps´any des´ıtky dokumentu QS Template. Po proveden´ı manu´aln´ıho testu tester zap´ıˇse v´ ysledky testu do QS dokumentu. QS dokument je automaticky sv´az´an s dokumentem QS Template.

32

Realizaˇcn´ı ˇc´ast

Ovˇeˇrov´ an´ı kvality implementace

Pokud byl test ne´ uspˇeˇsn´ y, tester nav´ıc vytvoˇr´ı dokument o chybˇe s odkazem na QS dokument s ne´ uspˇeˇsn´ ym manu´aln´ım testem. Manu´alnˇe byla tak´e testov´ana kaˇzd´a zmˇena uveˇrejnˇen´a ve verzovac´ım syst´emu. Toto testov´an´ı prob´ıhalo na z´akladˇe ovˇeˇrov´an´ı implementace dan´eho u ´kolu. Kaˇzd´ yu ´kol m´a sv˚ uj pr˚ uvodn´ı dokument. Tento dokument m´a odkaz na vˇsechny zmˇeny ve verzovac´ım syst´em t´ ykaj´ıc´ı se dan´eho u ´kolu. Po dokonˇcen´ı u ´kolu a code review je dokument pˇred´an testerovi na otestov´an´ı s instrukcemi ohlednˇe postupu. Instrukce pro manu´aln´ı otestov´an´ı mohou obsahovat jak popis postupu nebo odkaz na dokument QS Template, tak i zm´ınku, ˇze se jedn´a o technick´ yu ´kol, kter´ y nemˇen´ı ani nepˇrid´av´a funkˇcnost programu s pozn´amkou, kter´a oblast softwaru byla zmˇenou postiˇzena. Tester pot´e provede manu´aln´ı test ˇreˇsen´ı u ´kolu. Pokud test uspˇeje, tester oznaˇc´ı dokument u ´kolu a zmˇeny ve verzovac´ım syst´emu za otestovan´e.

3.3.2

Automatick´ e testov´ an´ı

Souˇca´st´ı v´ yvoje ˇreˇsen´ı vzd´alen´e spr´avy aplikac´ı v r´amci nemocniˇcn´ıho informaˇcn´ıho syst´emu byl v´ yvoj, spouˇstˇen´ı a spr´ava automatick´ ych testu. Pro psan´ı automatick´ ych testu byla vyuˇzita existuj´ıc´ı podpora. Z historick´ ych d˚ uvodu existuje podpora dvou frameworku pro psan´ı automatick´ ych testu. Starˇs´ı podpora, rozˇsiˇruj´ıc´ı framework JUint, se naz´ yv´a MPAUnit a novˇejˇs´ı verze, vych´azej´ıc´ı z frameworku TestNG, ACTUnit. Podpora MPAUnit vych´az´ı ze starˇs´ı verze JUnit frameworku, kde je zapotˇreb´ı dˇedit od abstraktn´ı testov´e tˇr´ıdy. MPAUnit m´a vlastn´ıho pˇredka pro testov´e tˇr´ıdy, kter´ y ˇreˇs´ı inicializaci prostˇred´ı a publikov´an´ı v´ ysledku testu. ACTUnit je novˇejˇs´ı podpora pro psan´ı automatick´ ych testu zaloˇzen´a na frameworku TestNG. Testy se p´ıˇs´ı pomoc´ı anotac´ı. Podpora vznikla v dobˇe, kdy psan´ı testu pomoc´ı anotac´ı nebylo s frameworkem JUnit moˇzn´e. O tom, ˇze psan´ı test˚ u pomoc´ı anotac´ı je obl´ıben´e, svˇedc´ı fakt, ˇze podpora pro psan´ı testu pomoc´ı anotac´ı pˇribyla tak´e do novˇejˇs´ıch verz´ı JUnit frameworku. Vˇetˇsina testu byla naps´ana s podporou pro testy ACTUnit. Jedin´a vˇec, kv˚ uli kter´e byl v nˇekter´ ych testech pouˇzit MPAUnit frameworkem, je spouˇstˇen´ı testu v separ´atn´ım procesu. Z´akladn´ı chov´an´ı automatick´ ych testu je, ˇze jsou vˇsechny testy spouˇstˇeny v jedn´e instanci virtu´aln´ıho stroje. MPAUnit dovoluje spustit test v nov´em procesu, coˇz je zapotˇreb´ı ve chv´ıli, kdy nˇekolik paraleln´ıch testu vyuˇz´ıv´a glob´aln´ı zdroje. Nebo v pˇr´ıpadˇe, kdy test potˇrebuje 33

Realizaˇcn´ı ˇc´ast

Ovˇeˇrov´ an´ı kvality implementace

testovat selh´aln´ı glob´aln´ıho zdroje, kter´ y po testu nedok´aˇze obnovit. Pˇr´ıpadnˇe test potˇrebuje nastavit specifick´e podm´ınky pro sv˚ uj bˇeh a navr´acen´ı p˚ uvodn´ıho stavu virtu´aln´ıho stroje nen´ı trivi´aln´ı. Automatick´e testy jsou spouˇstˇeny pravidelnˇe kaˇzd´ y den. Kv˚ uli poctu podporovan´ ych verz´ı produktu jsou testy pro danou verzi spouˇstˇeny pˇribliˇznˇe jednou t´ ydne. Pro kaˇzd´ y bˇeh testu je automaticky vytvoˇren dokument. V pˇr´ıpadˇe, ˇze test neuspˇel, je manu´alnˇe vytvoˇren dokument o ne´ uspˇeˇsn´em testu s odkazem na dokument o bˇehu testu. Dokument o ne´ uspˇeˇsn´em testu je napl´anov´an na opravu nebo pˇr´ımo pˇriˇrazen v´ yvoj´aˇri na opravu. Automatick´e testy monitorovac´ıho n´astroje jsou rozdˇeleny do dvou skupin: pomal´e a rychl´e. Rychl´e testy jsou urˇceny pro spuˇstˇen´ı na v´ yvoj´aˇrsk´em stroji pˇred kaˇzdou publikac´ı zmˇeny k´odu. Jejich bˇeh trv´a maxim´alnˇe jednotky minut. Bˇeh pomal´ ych testu zab´ır´a ˇra´dovˇe des´ıtky minut, a proto je spouˇstˇen pouze pˇred publikov´an´ım rozs´ahlejˇs´ı zmˇeny ve zdrojov´em k´odu.

34

4 Z´avˇer Pr´ace vznikla na z´akladˇe zad´an´ı rakousk´e firmy Systema Human Information Systems GmbH. Praktick´a ˇca´st, naps´an´ı programu, byla realizov´ana v prostˇred´ı firmy Querity s.r.o. v Plzni. Pˇr´ınos programu ACTMonitor je nesporn´ y. Spr´ava syst´emu byla do vzniku a realizace t´eto pr´ace n´aroˇcn´a a nepˇresn´a. Velice tˇeˇzko se hledaly v syst´emu pˇr´ıˇciny probl´em˚ u a ˇreˇsen´ı vˇetˇsinou vedla k restartov´an´ı sluˇzeb ˇci klientsk´ ych program˚ u. Administr´atoˇri serverov´ ych sluˇzeb z´ıskali v podobˇe ACTMonitoru mocn´ y n´astroj ke sledov´an´ı a sprovov´an´ı syst´emu MPA. Program ACTMonitor je v dobˇe odevzd´an´ı pr´ace nasazen v produkˇcn´ım syst´emu. F´aze v´ yvoje je jiˇz dokonˇcena a projekt je ve f´azi oprav chyb a u ´drˇzby. Pr˚ ubˇeˇznˇe jsou upravov´any funkce vzhledem ke zmˇen´am funkc´ı monitorovan´ ych program˚ u. Z hlediska bakal´aˇrsk´e pr´ace jakoˇzto dokumentu, kter´ y m˚ uˇze slouˇzit jako inspirace pro dalˇs´ı podobn´e pr´ace, je tˇreba alespoˇ n kr´atce zm´ınit nˇekolik vˇec´ı, kter´e se pˇri v´ yvoji aplikace osvˇedˇcily. yvoje JMX Pouˇzit´a technologie JMX je jednoznaˇcnˇe dobr´a volba a bˇehem v´ s n´ı nebyly prakticky ˇza´dn´e probl´emy. ´ Uroveˇ n zdrojov´ eho k´ odu Naprosto nejd˚ uleˇzitˇejˇs´ı pˇri v´ yvoji je ps´at ˇciteln´ y, samodokumentovateln´ y k´od. K jiˇz napsan´emu k´odu jsem se nˇekolikr´at vracel a zpoˇca´tku se mi st´avalo, ˇze jsem se ve vlastn´ım k´odu nevyznal. Postupem ˇcasu jsem si navykl na konvence a zdrojov´ y k´od se stal ˇcitelnˇejˇs´ı. Vzhledem k tomu, ˇze program byl vyv´ıjen za pomoci verzovac´ıho syst´emu, kdokoliv si mohl m´e zdrojov´e k´ody pˇreˇc´ıst a musel se v nich tak´e orientovat. N´ astroje pro zjiˇ st’ov´ an´ı defekt˚ u zdrojov´ eho k´ odu Bylo zaj´ımav´e zjistit, kolik potenci´aln´ıch probl´em˚ u bylo nalezeno ve zdrojov´em k´odu po zapnut´ı n´astroj˚ u pro zjiˇst’ov´an´ı defekt˚ u. Kdyby tyto n´astroje byly aktivn´ı uˇz od zaˇc´atku, jistˇe bych si uˇsetˇril ˇcas pˇri v´ yvoji. usob psan´ı zdroTest-driven development Test-driven development je zp˚ jov´eho k´odu na z´akladˇe automatick´ ych test˚ u. Program´ator nejdˇr´ıve nap´ıˇse automatick´ y test a aˇz pot´e v´ ykonn´ y k´od. Zpoˇc´atku se zd´a psan´ı 35

Z´avˇer

test˚ u zdlouhav´e a zbyteˇcn´e, ale po ˇcase se automatick´e testy ukazuj´ı jako neoceniteln´a pom˚ ucka pˇri refaktorov´an´ı a z´asah˚ u do st´avaj´ıc´ıho k´odu, kter´ y je tˇemito testy pokryt. Poˇ c´ıtejte s probl´ emy Jistˇe bych si uˇsetˇril spoustu ˇcasu upravov´an´ım st´avaj´ıc´ı implementace, kdyby byla od zaˇc´atku navrˇzena tak, ˇze pˇredpokl´ad´a, ˇze vˇse co se m˚ uˇze pokazit, tak se pokaz´ı. Napˇr´ıklad ovˇeˇrov´an´ı, zda-li je sluˇzba st´ale dostupn´a na sv´e adrese, protoˇze mohlo doj´ıt k jej´ımu n´asiln´emu ukonˇcen´ı. Pˇret´ıˇzen´a s´ıt’ a dalˇs´ı moˇzn´e probl´emy mus´ı b´ yt od zaˇc´atku br´any v potaz. Na z´avˇer bych r´ad podˇekoval vˇsem koleg˚ um, kteˇr´ı se pod´ıl´ı na v´ yvoji a u ´drˇzbˇe MPA. A v prvn´ı ˇradˇe dˇekuji inˇzen´ yru Jiˇr´ımu Kimlovi za bedliv´e bdˇen´ı nad projektem ACTMonitor, za hodiny str´aven´e nad code-review m´eho k´odu a za vˇse, co jsem se od tohoto v´ yborn´eho a zkuˇsen´eho program´atora nauˇcil.

36

Literatura [Ajay D. Kshemkalyani(2011)] AJAY D. KSHEMKALYANI, M. S. Distributed Computing: Principles, Algorithms, and Systems. New Delhi, India : firstbookstore, 2011. ISBN 0521189845. [Sullins(2002)] SULLINS, B. JMX in Action. Greenwich USA : Manning Publication Co., 2002. ISBN 1930110561. [Sun(2003)] JSR 160: JavaTM Management Extensions (JMX) Remote API. Sun Microsystems, 2003. Dostupn´e z: http://jcp.org/en/jsr/detail?id=160. [Sun(2009)] JSR 255: JavaTM Management Extensions (JMXTM) Specification 2.0. Sun Microsystems, 2009. Dostupn´e z: http://jcp.org/en/jsr/detail?id=255. [Sun(2002)] JSR 3: JavaTM Management Extensions (JMXTM) Specification. Sun Microsystems, 2002. Dostupn´e z: http://jcp.org/en/jsr/summary?id=3. [Sys(2011)] Domovsk´a str´anka. Systema Human Information Systems GmbH, 2011. Dostupn´e z: http://www.systema.info/en/home/. ˇ ˇ [TRON´ICEK(2011)] TRON´ICEK, Z. Pr˚ uvodce architekturou JEE aplikac´ı, 2011. Dostupn´e z: http://www.edumaster.cz/javadevelopers-solaris-administrators-day/pdf/JSD-2011GuideToArchitecture.pdf.

37