Serverový modul informačního systému s rozhraním pro

ˇ e vysoké uˇcen´ı technické v Praze Cesk´ Fakulta elektrotechnická Katedra poˇc´ıtaˇc˚ u

Diplomová práce

Serverov´ y modul informaˇ cn´ıho syst´ emu s rozhran´ım pro vzd´ alen´ e vol´ an´ı procedur Bc. Jan Suchan

Vedouc´ı práce: Ing. Tomáˇs Richta

Studijn´ı program: Elektrotechnika a informatika, strukturovan´ y, Navazuj´ıc´ı magistersk´ y Obor: V´ ypoˇcetn´ı technika 19. prosince 2010

iv

v

Podˇ ekov´ an´ı Chtˇel bych podˇekovat zejména mé snoubence za celkovou podporu nejen pˇri tvorbˇe této práce. D´ ale bych chtˇel podˇekovat vedouc´ımu práce za cenné rady a pˇripom´ınky. V neposledn´ı ˇradˇe bych pak rád podˇekoval m´ ym rodiˇc˚ um, kteˇr´ı mˇe celá studentská léta velmi podporovali, a také mému dobrému pˇr´ıteli a spoluˇzákovi, Petru Horskému, bez kterého ˇ by byl posledn´ı semestr na CVUT o mnoho obt´ıˇznˇejˇs´ı.

vi

vii

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem pr´ aci vypracoval samostatnˇe a pouˇzil jsem pouze podklady uvedené v pˇriloˇzeném seznamu. Nemám z´ avaˇzn´ y d˚ uvod proti uˇzit´ı tohoto ˇskoln´ıho d´ıla ve smyslu S60 Zákona ˇc. 121/2000 Sb., o pr´ avu autorském, o pr´ avech souvisej´ıc´ıch s právem autorsk´ ym a o zmˇenˇe nˇekter´ ych zákon˚ u (autorsk´ y z´ akon).

V Praze dne 19. 12. 2010

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

viii

Abstract Remote procedure call is a technology used from the very beginning of computer networks. This paper describes the principles, history and current importance of this technology in the first purely theoretical part. The goal of the second part is a design and an implementation of the server module of the information system, which uses remote procedure call for clientserver communication. This information system is used for the apartment buildings management. It is also possible to browse the state of the data to any date in the past or in the future. This function does not have any competing solution. Server module is implemented using Java Enteprise Edition platform, while at the database layer, the Hibernate framework as an implementation of Java Persistence API is used.

Abstrakt Vzdálené vol´ an´ı procedur je technologie pouˇz´ıvaná od samého poˇcátku poˇc´ıtaˇcov´ ych s´ıt´ı. Tato pr´ ace v prvn´ı ˇc´ asti, kter´ a je ryze teoretická, popisuje princip, historii i dneˇsn´ı v´ yznam této technologie. V ˇc´ asti druhé se pak nacház´ı návrh a implementace serverového modulu informaˇcn´ıho systému, kter´ y pro komunikaci s modulem klientsk´ ym vyuˇz´ıvá právˇe vzdáleného volán´ı procedur. Tento informaˇcn´ı systém slouˇz´ı ke správˇe bytov´ ych dom˚ u veden´ ych samotn´ ymi majiteli, sdruˇzen´ımi vlastn´ık˚ u ˇci druˇzstvy. Umoˇzn ˇuje nav´ıc procházet stav dat systému k libovolnému dni v minulosti i v budoucnosti. Touto funkc´ı ˇzádné konkurenˇcn´ı ˇreˇsen´ı nedisponuje. Serverov´ y modul je implementov´ an na platformˇe Java Enterprise Edition, pˇriˇcemˇz na u ´rovni databázové vrstvy je pouˇzit framework Hibernate jakoˇzto implementace Java Persistence API.

ix

x

Obsah ´ 1 Uvod 1.1 C´ıl pr´ ace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Struktura textu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Vzd´ alen´ e vol´ an´ı procedur 2.1 Princip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Prvn´ı zm´ınka o vzdáleném volán´ı procedur . . . . . . . . . . . 2.2.2 Vyuˇzit´ı distribuovan´ ych prostˇredk˚ u pomoc´ı RPC . . . . . . . . 2.2.3 Implementace RPC v rámci Xerox research internetwork . . . . 2.2.3.1 N´ avrh komponent RPC systému . . . . . . . . . . . . 2.2.3.2 Sémantika v pˇr´ıpadˇe selhán´ı komunikace ˇci algoritmu 2.2.3.3 Zajiˇstˇen´ı bezpeˇcnosti komunikace . . . . . . . . . . . 2.2.4 Dalˇs´ı v´ yvoj RPC . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.4.1 Sun Microsystems . . . . . . . . . . . . . . . . . . . . 2.2.4.2 Ostatn´ı firmy . . . . . . . . . . . . . . . . . . . . . . . 2.3 Dneˇsn´ı v´ yznam vzd´ aleného volán´ı procedur . . . . . . . . . . . . . . . 2.3.1 Rich Internet Applications . . . . . . . . . . . . . . . . . . . . . 2.3.2 Software jako sluˇzba . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Dalˇs´ı technologie a protokoly vycházej´ıc´ı z RPC . . . . . . . . . . . . . 2.5 Java Remote Method Invocation . . . . . . . . . . . . . . . . . . . . . 2.5.1 Princip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2 Pouˇzit´ı RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Anal´ yza 3.1 Informaˇcn´ı systém pro správu nemovitost´ı 3.2 St´ avaj´ıc´ı ˇreˇsen´ı . . . . . . . . . . . . . . . 3.2.1 Desktopové aplikace . . . . . . . . 3.2.1.1 Popis vybran´ ych aplikac´ı 3.2.1.2 Z´ avˇer z porovnán´ı . . . . 3.2.2 Webové aplikace . . . . . . . . . . 3.2.2.1 Popis vybran´ ych aplikac´ı 3.2.2.2 Z´ avˇer z porovnán´ı . . . . 3.3 Poˇzadavky na systém . . . . . . . . . . . . 3.3.1 Funkˇcn´ı poˇzadavky . . . . . . . . .

xi

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

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

. . . . . . . . . .

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

. . . . . . . . . .

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

. . . . . . . . . .

1 1 2

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

3 3 5 6 7 7 8 9 10 10 10 11 11 11 12 13 20 20 22

. . . . . . . . . .

25 25 25 26 26 30 30 30 33 33 33

xii

OBSAH

3.4

3.3.1.1 Prostˇredky pro správu bytov´ ych dom˚ u . . 3.3.1.2 Funkce ˇcasov´ ych ˇrez˚ u . . . . . . . . . . . . 3.3.2 Nefunkˇcn´ı poˇzadavky . . . . . . . . . . . . . . . . . 3.3.3 Poˇzadavky klientského modulu . . . . . . . . . . . . Scénáˇre pouˇzit´ı . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 Popis aktér˚ u . . . . . . . . . . . . . . . . . . . . . . 3.4.2 Podrobn´ y popis pˇr´ıpad˚ u uˇzit´ı . . . . . . . . . . . . . 3.4.2.1 Pˇr´ıpady uˇzit´ı modulu Building . . . . . . . 3.4.2.2 Pˇr´ıpady uˇzit´ı modulu Space . . . . . . . . 3.4.2.3 Pˇr´ıpady uˇzit´ı modulu Application . . . . . 3.4.2.4 Pˇr´ıpady uˇzit´ı v rámci práce s dynamick´ ymi

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . daty

4 V´ ybˇ er a popis technologi´ı 4.1 Vzdálené vol´ an´ı procedur (RPC) . . . . . . . . . . . . . . . . . 4.1.1 Popis a porovn´ an´ı technologi´ı . . . . . . . . . . . . . . . 4.1.2 Vybran´ a technologie: Java Enterprise Edition . . . . . . 4.1.2.1 Popis platformy Java EE . . . . . . . . . . . . 4.1.2.2 Enterprise Java Beans . . . . . . . . . . . . . . 4.1.2.3 Zabezpeˇcen´ı Java EE . . . . . . . . . . . . . . 4.2 Funkce ˇcasov´ ych ˇrez˚ u. . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Moˇznosti n´ avrhu temporárn´ı funkˇcnosti . . . . . . . . . 4.2.2 Popis zvolené moˇznosti pro návrh temporárn´ı funkˇcnosti 4.3 Datab´ azov´ a vrstva v r´ amci Java EE . . . . . . . . . . . . . . . 4.3.1 Java Persistence API . . . . . . . . . . . . . . . . . . . . 4.3.2 Popis a porovn´ an´ı implementac´ı Java Persistence API . 4.3.3 Vybran´ a implementace: Hibernate . . . . . . . . . . . . 4.3.4 Datové u ´loˇziˇstˇe . . . . . . . . . . . . . . . . . . . . . . .

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

. . . . . . . . . . .

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

. . . . . . . . . . .

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

. . . . . . . . . . .

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

5 N´ avrh ˇ reˇ sen´ı 5.1 Datov´ y model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Modul Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2 Modul Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3 Modul Building . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.4 Modul Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.5 Modul Application . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Aplikaˇcn´ı vrstva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Z´ akladn´ı operace v temporárn´ı databázi . . . . . . . . . . . . . 5.2.1.1 Operace s klasick´ ymi objekty obsahuj´ıc´ımi dynamická 5.2.1.2 Operace s M:N vztahov´ ymi entitami . . . . . . . . . . 5.2.2 Zabezpeˇcen´ı funkc´ı systému dle uˇzivatelsk´ ych práv . . . . . . . 5.2.2.1 Aspektovˇe orientované programován´ı . . . . . . . . . 5.2.2.2 Pouˇzit´ı AOP pro kontrolu uˇzivatelsk´ ych práv . . . . .

. . . . . . . . . . .

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

. . . . . . . . . . .

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

. . . . . . . . . . .

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

. . . . . . . . . . . . . . . . . . . . . . . . data . . . . . . . . . . . .

. . . . . . . . . . .

33 35 36 37 37 37 38 40 41 42 42

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

45 45 45 46 47 48 49 50 50 51 53 54 54 55 55

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

57 57 57 58 59 60 61 63 63 63 65 67 67 67

OBSAH

xiii

6 Implementace 6.1 Struktura projektu . . . . . . . . . . . . . . . . . . . . 6.2 Datab´ azov´ a vrstva . . . . . . . . . . . . . . . . . . . . 6.2.1 Implementaˇcn´ı rozd´ıly v entitách oproti návrhu ´ 6.2.2 Upravy dle poˇzadavk˚ u klientského modulu . . 6.2.3 Spring ROO . . . . . . . . . . . . . . . . . . . . 6.3 Aplikaˇcn´ı logika . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Uk´ azka funkˇcn´ıch metod EJB . . . . . . . . . . 6.3.2 Zabezpeˇcen´ı funkc´ı dle uˇzivatelsk´ ych práv . . . 6.3.3 Ostatn´ı funkce aplikaˇcn´ı logiky . . . . . . . . . 6.3.4 V´ yjimky . . . . . . . . . . . . . . . . . . . . . . 6.4 Napojen´ı rozd´ıln´ ych klientsk´ ych modul˚ u . . . . . . . . 6.5 Spr´ ava projektu . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Subversion . . . . . . . . . . . . . . . . . . . . 6.5.1.1 Z´ akladn´ı pojmy . . . . . . . . . . . . 6.5.1.2 Pouˇz´ıv´ an´ı Subversion . . . . . . . . . 6.5.2 Apache Maven . . . . . . . . . . . . . . . . . . 6.5.2.1 Project Object Model . . . . . . . . . 6.5.2.2 Struktura Maven projektu . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

69 69 70 70 70 71 72 72 72 72 73 74 77 77 77 78 79 80 81

7 Testov´ an´ı 7.1 R˚ uzné zp˚ usoby testov´ an´ı Enterprise Java Beans 7.1.1 Moˇznosti out-of-container testován´ı . . . 7.1.2 Moˇznosti in-container testován´ı . . . . . 7.2 Vybran´ y zp˚ usob testov´ an´ı . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

83 83 84 87 89

8 Z´ avˇ er 8.1 Zhodnocen´ı v´ ysledk˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Dalˇs´ı v´ yvoj aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

91 91 92

Literatura

93

A Seznam zkratek

99

B Popis instalace B.1 Java Runtime Environment B.2 Server Glassfish . . . . . . . B.3 Nasazen´ı EJB modulu . . . B.4 Spuˇstˇen´ı serveru . . . . . . B.5 Pˇripraven´ y EJB modul . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

103 103 103 103 103 104

C Uk´ azky k´ odu 105 C.1 Funkˇcn´ı metody EJB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 C.2 Interceptor na kontrolu uˇzivatelsk´ ych práv . . . . . . . . . . . . . . . . . . . . 108 D Obsah pˇ riloˇ zen´ eho CD

109

xiv

OBSAH

Seznam obr´ azk˚ u 2.1 2.2

2.3 2.4 2.5 2.6 2.7

Z´ akladn´ı princip komunikace pomoc´ı vzdáleného volán´ı procedur. . . . . . . . Komponenty RPC systému v implementaci v rámci Xerox research internetwork a jejich vz´ ajemn´ a komunikace. Obrázek je pˇrevzat´ y z [9] a zámˇernˇe je ponech´ an v angliˇctinˇe z d˚ uvodu pouˇzit´ı zavedené anglické terminologie. . . . Architektura nasazen´ı softwaru jako sluˇzby. Obrázek je pˇrevzat´ y z [63]. . . . . Struktura XML zpr´ avy protokolu SOAP. . . . . . . . . . . . . . . . . . . . . . Architektura protokolu DCOM. Obrázek je pˇrevzat´ y z [1]. . . . . . . . . . . . Pouˇzit´ı n´ avrhového vzoru Proxy pˇri RMI komunikaci mezi klientem a serverem. Obr´ azek je pˇrevzat´ y z [66]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vrstevnat´ a architektura RMI. Obrázek je pˇrevzat´ y z [66]. . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Uk´ azka z programu SSB2000 od firmy STARLIT s.r.o. . . . . . . . . . . . . . Uk´ azka z programu SOFTWARE 5P od firmy Ing. Oldˇrich Florian. . . . . . . Uk´ azka z programu Cactus Domus od firmy CÍGLER SOFTWARE, a.s. . . . Uk´ azka z aplikace SSBnet od firmy STARLIT s.r.o. . . . . . . . . . . . . . . . Uk´ azka z webové nadstavby aplikace WinDomy od firmy O.K. Soft. . . . . . Uk´ azka z aplikace Building manager od firmy Ikon s.r.o. . . . . . . . . . . . . Historick´ a oprava dynamické informace - ˇreknˇeme, ˇze zpˇetnˇe ukládáme do systému typy jedné m´ıstnosti v bytˇe tak, jak byly postupnˇe rekonstruovány. Pˇri zad´ av´ an´ı ale udˇel´ ame chybu (1), kterou potˇrebujeme následnˇe opravit (2). 3.8 Smaz´ an´ı historické zmˇeny - do systému jsme omylem zadali rekonstrukci m´ıstnosti, kter´ a vˇsak nebyla provedena, proto ji potˇrebujeme smazat (1) a následnˇe urˇcit, jak´ a sousedn´ı hodnota vypln´ı dan´ y ˇcasov´ yu ´sek (2). . . . . . . . . . . . 3.9 Dˇediˇcnost aktér˚ u. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.10 Pˇr´ıpady uˇzit´ı zohledˇ nuj´ıc´ı funkce priority (1). . . . . . . . . . . . . . . . . . . ´ 3.11 Pˇr´ıpady uˇzit´ı v pˇr´ıpadˇe u ´pravy“objektu. Upravou se mysl´ı jak u ´prava jiˇz ” vytvoˇreného objektu, tak i pˇridán´ı nového ˇci smazán´ı stávaj´ıc´ıho. . . . . . . . 3.12 Pˇr´ıpady uˇzit´ı pro pr´ aci s dynamick´ ymi daty. . . . . . . . . . . . . . . . . . . .

4

9 12 15 18 21 22 26 28 29 31 31 32

36

37 38 39 40 43

4.1 4.2 4.3

Vrstevnat´ a architektura Java Enterprise Edition. . . . . . . . . . . . . . . . . Entita se statick´ ymi a dynamick´ ymi informacemi. . . . . . . . . . . . . . . . . M:N historick´ a entita. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48 52 52

5.1 5.2 5.3

Datov´ y model modulu Type. . . . . . . . . . . . . . . . . . . . . . . . . . . . Datov´ y model modulu Personal. . . . . . . . . . . . . . . . . . . . . . . . . . Datov´ y model modulu Building. . . . . . . . . . . . . . . . . . . . . . . . . .

58 59 60

xv

´ U ˚ SEZNAM OBRAZK

xvi

5.4 5.5 5.6

Datov´ y model modulu Space. . . . . . . . . . . . . . . . . . . . . . . . . . . . Datov´ y model modulu Application. . . . . . . . . . . . . . . . . . . . . . . . . Aspektovˇe orientované programován´ı pˇri pouˇzit´ı s Enterprise Java Bean metodou. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diagram aktivit pro funkci, která kontroluje oprávnˇen´ı uˇzivatele ke spuˇstˇen´ı EJB metody. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61 62

6.1 6.2 6.3

Nepˇredv´ıdatelné v´ yjimky serverového modulu, které znaˇc´ı selhán´ı programu. . V´ yjimky serverového modulu, které jsou propagovány do modulu klientského. Struktura adres´ aˇre Maven projektu. . . . . . . . . . . . . . . . . . . . . . . .

74 75 81

7.1

Diagram fungov´ an´ı testovac´ıho frameworku Cactus. Obrázek je pˇrevzat´ y z [15]. 87

5.7

68 68

Seznam tabulek 6.1 6.2

Bal´ıˇcky serverového modulu. . . . . . . . . . . . . . . . . . . . . . . . . . . . Dˇediˇcnost v JPA entit´ ach. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69 70

7.1

Srovn´ an´ı testov´ an´ı EJB mimo J2EE kontejner a uvnitˇr J2EE kontejneru. . .

84

xvii

xviii

SEZNAM TABULEK

Kapitola 1

´ Uvod Na konci ˇsedes´ at´ ych let dvac´ atého stolet´ı se na svˇetˇe objevily prvn´ı osobn´ı poˇc´ıtaˇce. Mimo nich vˇsak st´ ale jeˇstˇe existovaly velké laboratorn´ı poˇc´ıtaˇce, tzv. Mainframe1 . Problém byl v tom, ˇze pˇres vˇsechny v´ yhody plynouc´ı z malé velikosti osobn´ıch poˇc´ıtaˇc˚ u nebyly tyto natolik v´ ykonné, aby mohly zpracov´ avat sloˇzité v´ ypoˇcty. Pˇredstavovaly sp´ıˇse jakési komunikaˇcn´ı termin´ aly. Bylo proto nutno vytvoˇrit nˇejak´ y mechanismus, kter´ ym by mohly tyto termin´ aly delegovat sloˇzitˇejˇs´ı nebo dokonce vˇsechny v´ ypoˇcty v´ ykonn´ ym poˇc´ıtaˇc˚ um. V devades´ at´ ych letech zaˇcaly osobn´ı poˇc´ıtaˇce dosahovat takového v´ ykonu, ˇze se od tohoto principu komunikace postupnˇe upouˇstˇelo. S rozvojem internetu a se stále se zvyˇsuj´ıc´ımi nároky na v´ ykon by se vˇsak dalo ˇr´ıci, ˇze se nyn´ı vrac´ıme k p˚ uvodn´ı myˇslence. Jako pˇr´ıklad m˚ uˇzeme uvést operaˇcn´ı systém Chrome OS vyv´ıjen´ y firmou Google, kter´ y bude slouˇzit jen jako termin´ al pro internetové aplikace.

1.1

C´ıl pr´ ace

Tato pr´ ace m´ a za u ´kol popsat princip vzdáleného volán´ı procedur2 , kter´ y byl (a stále je) pouˇz´ıv´ an v kontextu v´ yˇse zm´ınˇené komunikace dvou poˇc´ıtaˇc˚ u. Tento zp˚ usob se v dobˇe rozvoje distribuovan´ ych v´ ypoˇct˚ u uk´ azal jako nejlepˇs´ı a nyn´ı se vyuˇz´ıvá pro bˇeˇznou klient-server komunikaci (jmenujme napˇr´ıklad implementaci Java RMI, která je souˇcást´ı Enterprise Java aplikac´ı). Pr´ ace d´ ale obsahuje n´ avrh a implementaci informaˇcn´ıho systému (resp. jeho serverové ˇcásti) pro spr´ avu bytov´ ych dom˚ u. Tento IS mus´ı splˇ novat n´ asleduj´ıc´ı poˇzadavky: ∙ pouˇzit´ı platformy Java 5 nebo vyˇsˇs´ı, ∙ poskytnut´ı prostˇredk˚ u pro správu bytov´ ych dom˚ u s r˚ uzn´ ymi typy majitel˚ u (napˇr. druˇzstvo ˇci spoleˇcenstv´ı vlastn´ık˚ u), 1

Dnes si m˚ uˇzeme pod pojmem Mainframe pˇredstavit poˇc´ıtaˇcov´ y systém pouˇz´ıvan´ y velk´ ymi firmami zejména pro urˇcité kritické aplikace. 2 Pro vzd´ alené vol´ an´ı procedur se pouˇz´ıv´ a zaveden´ y anglick´ y n´ azev Remote Procedure Call, jehoˇz zkratku (RPC) budeme nad´ ale v textu pouˇz´ıvat.

1

´ KAPITOLA 1. UVOD

2

∙ moˇznost proch´ azet stav systému k libovolnému dni v minulosti, ∙ komunikace s klientsk´ ym modulem mus´ı b´ yt zajiˇstˇena pomoc´ı vzdáleného volán´ı procedur. Jeden z moˇzn´ ych klientsk´ ych modul˚ u (webovou aplikaci) implementoval kolega Petr Horsk´ y ve své diplomové pr´ aci Klientsk´ y modul informaˇcn´ıho systému jako plnohodnotná ” webová aplikace“. V pr˚ ubˇehu v´ yvoje bylo tedy napojen´ı klientského modulu testováno právˇe t´ımto prototypem.

1.2

Struktura textu

Práce obsahuje mimo u ´vodu n´ asleduj´ıc´ı kapitoly: ∙ Vzd´ alen´ e vol´ an´ı procedur (kapitola 2) - tato kapitola pˇredstavuje teoretickou ˇcást práce. Vysvˇetl´ıme si nejprve princip a fungován´ı RPC, poté pop´ıˇseme vzdálené volán´ı procedur z historického i souˇcasného hlediska a na závˇer uvedeme nˇekteré implementace RPC s d˚ urazem na implementaci v jazyce Java (Java RMI), kterou budeme pouˇz´ıvat v naˇsem programu. ∙ Anal´ yza (kapitola 3) - v této kapitole podrobnˇe probereme poˇzadavky na informaˇcn´ı systém, vˇcetnˇe porovn´ an´ı st´ avaj´ıc´ıch ˇreˇsen´ı. ∙ V´ ybˇ er technologi´ı (kapitola 4) - pˇred samotn´ ym návrhem je d˚ uleˇzité porovnat technologie, jejichˇz pouˇzit´ı pˇripad´ avu ´vahu, a vybrat z nich ty nejlepˇs´ı. ∙ N´ avrh ˇ reˇ sen´ı (kapitola 5) - tato kapitola obsahuje návrh ˇreˇsen´ı s pouˇzit´ım vybran´ ych technologi´ı. ∙ Implementace (kapitola 6) - zde pop´ıˇseme implementaci navrˇzen´ ych ˇreˇsen´ı z kapitoly 6. ∙ Testov´ an´ı (kapitola 7) - kaˇzd´ a aplikace mus´ı b´ yt pˇred nasazen´ım otestována, v této kapitole tedy pop´ıˇseme zp˚ usob testován´ı, kter´ y jsme si zvolili. ∙ Z´ avˇ er (kapitola 8) - zde pak zhodnot´ıme celkov´ y v´ ysledek a pˇr´ınos práce. Pˇr´ılohy: ∙ A - Seznam zkratek ∙ B - Popis instalace ∙ C - Ukázky k´ odu ∙ D - Obsah pˇriloˇzeného CD

Kapitola 2

Vzd´ alen´ e vol´ an´ı procedur Vzdálené vol´ an´ı procedur neboli Remote Procedure Call (RPC) je technologie, která m˚ uˇze b´ yt pouˇzita mnoha zp˚ usoby z d˚ uvodu jej´ı obecnosti. Prvn´ı implementace RPC byla pouˇzita v´ yhradnˇe pro distribuované v´ ypoˇcty, dnes je naopak bˇeˇzné pouˇzit´ı v internetov´ ych aplikac´ıch.

2.1

Princip

Je vidˇet, ˇze r˚ uznost implementac´ı RPC m˚ uˇze b´ yt tedy opravdu velká, popiˇsme si vˇsak nyn´ı základn´ı princip, kter´ y maj´ı vˇsechny implementace spoleˇcn´ y. Tento princip se totiˇz v zásadˇe nezmˇenil od poˇc´ atku této technologie v osmdesát´ ych letech dvacátého stolet´ı, coˇz je v oblasti v´ ypoˇcetn´ı techniky sp´ıˇse neobvyklé. V´ıce o historii RPC se dozv´ıte v ˇcásti 2.2. Na obr´ azku 2.1 je zn´ azornˇena komunikace klientského poˇc´ıtaˇce (ten, kter´ y volá vzdálenou proceduru) a serverového poˇc´ıtaˇce (ten, kter´ y vzdálenou proceduru vykonává). 1. Klientsk´ y program (pˇr´ıpadnˇe pˇr´ımo uˇzivatel) nejprve stanov´ı název vzdálené procedury spolu s parametry, se kter´ ymi chce proceduru vykonat, 2. tato informace je pˇrenesena pˇres s´ıt’ na server (jak´ ym zp˚ usobem, to uˇz závis´ı na konkrétn´ı implementaci), 3. server vykon´ a proceduru se zadan´ ymi parametry (coˇz je standardn´ı lokáln´ı volán´ı), 4. v´ ysledek procedury je posl´ an zpˇet pˇres s´ıt’ klientskému poˇc´ıtaˇci, 5. kter´ y v´ ysledek zpracuje obvykl´ ym zp˚ usobem, jako by pocházel z volán´ı lokáln´ı procedury. V´ yˇse popsan´ y zp˚ usob komunikace mezi klientem a serverem je velmi obecn´ y, avˇsak pr´ avˇe proto je platn´ y pro vˇsechny implementace. Nyn´ı zm´ın´ıme nˇekteré principy protokolu a poˇzadavky na nˇej tak, jak je uv´ ad´ı RFC (Request for Comments1 ) 1050 [79], coˇz je v˚ ubec prvn´ı RFC uv´ adˇej´ıc´ı specifikaci protokolu RPC. Jaké byly dalˇs´ı dokumenty popisuj´ıc´ı protokol se 1

Request for Comments jsou neform´ aln´ı standardy z oblasti internetu vyd´ avané r˚ uzn´ ymi firmami ˇci skupinami lid´ı.

3

´ ´ VOLAN ´ Í PROCEDUR KAPITOLA 2. VZDALEN E

4

Klient Název vzdálené procedury + argumenty Zpracování výsledku

Síť Paket(y) s voláním

Paket(y) s výsledkem

Server Provedení procedury se zadanými argumenty Vytvoření odpovědi (výsledku)

Obrázek 2.1: Z´ akladn´ı princip komunikace pomoc´ı vzdáleného volán´ı procedur. dozv´ıte v ˇcásti 2.2. N´ıˇze uvedené principy a poˇzadavky se vˇsak od roku 1988 aˇz do posledn´ı specifikace z roku 2009 nezmˇenily. Je d˚ uleˇzité si uvˇedomit, ˇze aˇckoli byl protokol RPC zaveden právˇe proto, aby byl co nejbliˇzˇs´ı standardn´ımu lok´ aln´ımu vol´ an´ı procedur, je zde nˇekolik podstatn´ ych rozd´ıl˚ u: 1. Oˇ setˇ ren´ı chyb: oproti lok´ aln´ım procedurám mus´ıme zajistit oˇsetˇren´ı chyb plynouc´ıch ze selhán´ı komunikace nebo serveru. 2. Probl´ em s ukazateli: nelze pos´ılat ukazatele jako parametr, protoˇze nemaj´ı v serverovém adresn´ım prostoru smysl, nam´ısto ukazatel˚ u se pouˇz´ıvaj´ı globáln´ı identifikátory (promˇenné). 3. Glob´ aln´ı promˇ enn´ e: z d˚ uvodu zm´ınˇeného v pˇredchoz´ım bodˇe (server nemá pˇr´ıstup do adresn´ıho prostoru klienta) procedura nesm´ı mˇenit tyto globáln´ı promˇenné ani jinak ovlivˇ novat program mimo n´ avratové hodnoty. 4. Rychlost: vol´ an´ı vzd´ alen´ ych procedur je v´ yraznˇe pomalejˇs´ı neˇz volán´ı tˇech lokáln´ıch. 5. Autentizace: Specifikace neuv´ ad´ı nutnost komunikovat pomoc´ı RPC pˇres zabezpeˇcenou s´ıt’, m˚ uˇze b´ yt tedy vyˇzadov´ ano ovˇeˇren´ı pravosti klienta i serveru. Vzhledem k tomu, ˇze pˇred zaveden´ım RPC nebyly ˇzádné pˇredchoz´ı zp˚ usoby volán´ı vzdálen´ ych operac´ı na jiném poˇc´ıtaˇci nijak standardizovány, RFC 1050 [79] uvád´ı d˚ uleˇzité poˇzadavky na protokol vzd´ aleného vol´ an´ı procedur: 1. volaná procedura mus´ı b´ yt jednoznaˇcnˇe identifikována, 2. pˇri pˇr´ıchodu odpovˇedi od serveru mus´ı klient jednoduˇse zjistit, ke kterému volán´ı procedury odpovˇed’ patˇr´ı, 3. protokol mus´ı poskytnout prostˇredky pro autentizaci klienta serveru a naopak. Mimo tˇechto poˇzadavk˚ u je vhodné, aby implementace protokolu obsahovala funkce, které zajist´ı oˇsetˇren´ı tˇechto chyb: 1. nekompatibilita RPC protokolu,

2.2. HISTORIE

5

2. rozd´ılné verze protokolu, kter´ y pouˇz´ıvá klient a server, 3. chyby na u ´rovni vol´ an´ı procedury (napˇr. zadán nepodporovan´ y typ parametru), 4. selh´ an´ı autentizace, 5. jak´ akoli dalˇs´ı chyba, kter´ a zp˚ usob´ı, ˇze nen´ı poˇzadovaná vzdálená procedura zavol´ ana. Uvedli jsme tedy z´ akladn´ı princip a schéma komunikace pomoc´ı RPC a popsali jsme d˚ uleˇzité poˇzadavky na protokol, které se od jeho prvn´ı pˇredstavené specifikace nezmˇenily. Následuj´ıc´ı text popisuje v´ yvoj protokolu RPC od v˚ ubec prvn´ı zm´ınky o této technice pˇres prvn´ı re´ alnou implementaci, kter´ a poloˇzila základ nˇekter´ ym implementac´ım v dneˇsn´ıch modern´ıch programovac´ıch jazyc´ıch, aˇz po v´ yznam RPC v souˇcasnosti.

2.2

Historie

V roce 1969 vznikla poˇc´ıtaˇcov´ a s´ıt’ ARPANET2 , která poloˇzila základy dneˇsn´ıho internetu. Tato s´ıt’ byla vytvoˇrena kv˚ uli potˇrebˇe sd´ılet r˚ uzné prostˇredky a informace mezi poˇc´ıtaˇci vzdálen´ ymi mnoho des´ıtek ˇci stovek kilometr˚ u. Distribuované prostˇredky se v té dobˇe pouˇz´ıvaly v zásadˇe dvˇema r˚ uzn´ ymi zp˚ usoby, bud’ ∙ pˇr´ımo ˇclovˇekem u daného poˇc´ıtaˇce, kter´ y zadával konkrétn´ı pˇr´ıkazy a z´ıskal od vzd´ aleného poˇc´ıtaˇce nˇejakou odpovˇed’, nebo ∙ samotn´ ymi programy, které k nˇejakému v´ ypoˇctu pouˇzili v´ ypoˇcetn´ı kapacitu vzdáleného poˇc´ıtaˇce. Pokud chtˇel aplikaˇcn´ı programátor pouˇz´ıt ve svém programu nˇejaké vzdálené prostˇredky, musel pouˇz´ıt protokol, kter´ y k tomu byl urˇcen - napˇr´ıklad FTP (File Transfer Protocol) ˇci RJE (Remote Job Entry Protocol). Komunikace se vzdálen´ ym poˇc´ıtaˇcem byla definov´ ana pomoc´ı pˇr´ıkazu a odpovˇedi, tedy Command a Response. Takto vypadala syntaxe této komunikace: command-name <SP> parameter response-number <SP> text Pˇr´ıkaz se tedy skl´ adal z n´ azvu a textového parametru a odpovˇed’ obsahovala tˇr´ıˇc´ıseln´ y kód (pro volaj´ıc´ı program) a textov´ y v´ ysledek (pro pˇr´ıpadné zobrazen´ı uˇzivateli). Kaˇzd´ y protokol mˇel samozˇrejmˇe pˇr´ıkazy a odpovˇedi r˚ uzné, syntaxi vˇsak zachovávaly stejnou. Systém Command/Response nicménˇe nebyl ideáln´ı, mˇel nˇekolik nev´ yhod zejména pro program´ atory, kteˇr´ı ho ve sv´ ych aplikac´ıch chtˇeli pouˇz´ıt: ∙ neexistoval ˇz´ adn´ y standard tohoto systému, 2 Advanced Research Projects Agency Network (zkr´ acenˇe ARPANET) byla v´ yzkumn´ a s´ıt’, kter´ a ze zaˇca ´tku propojovala nˇekolik univerzit, ale postupnˇe se rozrostla na des´ıtky tis´ıc poˇc´ıtaˇc˚ u po celém svˇetˇe. Nab´ızela pouˇzit´ı r˚ uzn´ ych protokol˚ u, napˇr´ıklad pˇredch˚ udce dneˇsn´ıho e-mailu [23].


6

∙ program´ atoˇri tak museli sami implementovat vˇzdy znovu knihovny pro pouˇzit´ı distribuovan´ ych prostˇredk˚ u, ∙ jak je patrno ze syntaxe, nebylo moˇzné poslat v jednom okamˇziku v´ıce parametr˚ u, napˇr´ıklad pˇrejmenov´ an´ı souboru (kde potˇrebujeme znát p˚ uvodn´ı a nov´ y název) muselo b´ yt provedeno dvˇema pˇr´ıkazy, ∙ parametry byly pouze textové, ˇz´ adné jiné typy nebyly povoleny.

2.2.1

Prvn´ı zm´ınka o vzd´ alen´ em vol´ an´ı procedur

Zm´ınˇené nev´ yhody vedly k v˚ ubec prvn´ı myˇslence o vzdáleném volán´ı procedur v RFC 707 [89] z roku 1975. Tato myˇslenka vych´ az´ı z faktu, ˇze je pro programátora nejpˇrirozenˇejˇs´ı pouˇzit´ı procedur, které vyuˇz´ıv´ a k lok´ aln´ım u ´kon˚ um. Aby byly tedy vzdálené prostˇredky stejnˇe dostupné, bylo by ide´ aln´ı m´ıt moˇznost obsluhovat je stejn´ ym zp˚ usobem jako ty lokáln´ı. V RFC 707 byly definov´ any poˇzadavky, které by mˇel nov´ y protokol, nahrazuj´ıc´ı systém Command/Response, splˇ novat: ∙ Podpora stejn´ ych funkc´ı jako v systému Command/Response: 1. vyvol´ an´ı jakéhokoli pojmenovaného pˇr´ıkazu ˇci funkce implementovaného vzdálen´ ym procesem, 2. z´ısk´ an´ı v´ ysledk˚ u jak pro uˇzivatele, kterému budou zobrazeny, tak pro volaj´ıc´ı lokáln´ı program, kter´ y je m˚ uˇze dál zpracovat. ∙ Odstranˇen´ı zn´ am´ ych nedostatk˚ u p˚ uvodn´ıho protokolu“: ” 3. libovoln´ y poˇcet parametr˚ u jako vstup pro jeden pˇr´ıkaz, 4. podpora r˚ uzn´ ych typ˚ u, nejen textov´ ych ˇretˇezc˚ u, 5. procedura mus´ı umˇet tyto r˚ uzné parametry pˇrij´ımat pro vstup, jakoˇzto i vracet v´ ysledky r˚ uzn´ ych typ˚ u jako v´ ystup. ∙ Podpora nov´ ych funkc´ı: 6. umoˇznit procesu bˇeˇz´ıc´ımu na serveru spouˇstˇet pˇr´ıkazy v procesu na klientu (nerozliˇsovat tedy postaven´ı klientského a serverového poˇc´ıtaˇce), 7. moˇznost spuˇstˇen´ı dvou a v´ıce pˇr´ıkaz˚ u bˇeˇz´ıc´ıch zároveˇ n, 8. volaj´ıc´ı proces by mˇel m´ıt moˇznost oznaˇcit odpovˇed’ jako nepotˇrebnou, tedy ulehˇcit tak s´ıt’ovému provozu. Z v´ yˇse uveden´ ych poˇzadavk˚ u vych´ az´ı dle RFC 707 návrh nového protokolu, kter´ y vypadá následovnˇe: message-type=CALL [tid] procedure-name arguments message-type=RETURN tid outcome results Vˇsechny ˇcásti navrhované syntaxe splˇ nuj´ı v´ yˇse uvedené poˇzadavky. Stoj´ı snad za zm´ınku pouze voliteln´ y parametr tid, coˇz je identifikátor transakce pouˇz´ıvan´ y pˇri soubˇeˇzn´ ych operac´ıch nebo pˇri odm´ıtnut´ı v´ ysledku, jak bylo uvedeno v bodu 8.

2.2. HISTORIE

2.2.2

7

Vyuˇ zit´ı distribuovan´ ych prostˇ redk˚ u pomoc´ı RPC

C´ılem novˇe vytvoˇreného protokolu by tedy mˇela b´ yt jednoduchost v pouˇzit´ı distribuovan´ ych prostˇredk˚ u, které bude moci programátor obsluhovat stejnˇe jako ty lokáln´ı. Vzdálené prostˇredky se budou moci pouˇz´ıvat jako kolekce vzdálen´ ych podprocedur. Uˇz od poˇc´ atku dob, kdy poˇc´ıtaˇce zastupovaly lidi v ˇreˇsen´ı nejr˚ uznˇejˇs´ıch u ´loh, sloˇzitost tˇechto u ´loh pˇrevyˇsovala kapacitu jednoho poˇc´ıtaˇce. Ano, pˇred ˇctyˇriceti lety to byly u ´lohy, které dnes vyˇreˇs´ı poˇc´ıtaˇc za nˇekolik sekund oproti tehdejˇs´ım nˇekolika t´ ydn˚ um, ale lidé poˇr´ ad nacházej´ı nové a nové problémy, které chtˇej´ı vyˇreˇsit a jedin´ y poˇc´ıtaˇc k tomu stále nen´ı dostaˇcuj´ıc´ı. Jako aktu´ aln´ı pˇr´ıklad m˚ uˇzeme uvést v´ ypoˇcet pˇredpovˇedi poˇcas´ı, kter´ y je natolik obt´ıˇzn´ y, ˇze ani dneˇsn´ı nejv´ ykonnˇejˇs´ı poˇc´ıtaˇce k tomu nejsou dost v´ ykonné. Vznik protokolu RPC jako prostˇredku pro pouˇzit´ı distribuovan´ ych prostˇredk˚ u je tedy velmi v´ yznamn´ ym miln´ıkem v oblasti poˇc´ıtaˇc˚ u. Poloˇzil základy snadnˇejˇs´ı tvorby aplikac´ı vyuˇz´ıvaj´ıc´ıch ke sv´ ym v´ ypoˇct˚ um v´ıce neˇz jeden poˇc´ıtaˇc.

2.2.3

Implementace RPC v r´ amci Xerox research internetwork

Od prvn´ı zm´ınky o RPC uplynulo témˇeˇr deset let, ale vˇsechny dokumenty, které následnˇe popisovaly fungov´ an´ı vzd´ aleného volán´ı procedur, se zamˇeˇrovaly pouze na teoretickou rovinu. Aˇz v r´ amci v´ yzkumné laboratoˇre Xerox3 vznikl ˇclánek [9] popisuj´ıc´ı v˚ ubec prvn´ı implementaci RPC. Vzhledem k tomu, ˇze se jedná o prvn´ı ˇreˇsen´ı této problematiky, ze kterého poté postupnˇe vych´ azej´ı vˇsechny následuj´ıc´ı, probereme si tuto implementaci podrobnˇeji. Vzd´ aleného vol´ an´ı procedur zde bylo pouˇzito jako prostˇredek pro komunikaci mezi poˇc´ıtaˇci zpracov´ avaj´ıc´ımi distribuované v´ ypoˇcty. RPC má dle [9] nˇekolik zásadn´ıch v´ yhod oproti ostatn´ım zp˚ usob˚ um komunikace: ∙ jednoduch´ a s´ emantika umoˇzn ˇuj´ıc´ı jednoduˇsˇs´ı programován´ı distribuovan´ ych v´ ypoˇct˚ u, ∙ efektivita komunikace - volán´ı procedur je jednoduché a pˇri komunikaci se nepˇren´ aˇs´ı ˇz´ adn´ a nadbyteˇcn´ a data, ∙ obecn´ e pojet´ı komunikace - procedury jsou v lokáln´ım programu hlavn´ım stavebn´ım prvkem a tak tomu je i pˇri distribuovaném v´ ypoˇctu. Pˇri návrhu implementace byl kladen d˚ uraz na nˇekolik vˇec´ı: ∙ bylo d˚ uleˇzité program´ atora oprostit od programován´ı sloˇzit´ ych knihoven, umoˇzn ˇuj´ıc´ıch komunikaci s ostatn´ımi poˇc´ıtaˇci, aby se mohl soustˇredit pouze na konstrukci algoritmu pro distribuovan´ y v´ ypoˇcet, ∙ d´ ale bylo vhodné vytvoˇrit takovou implementaci RPC, která bude velmi efektivn´ı a samotn´ a komunikace mezi poˇc´ıtaˇci nebude zatˇeˇzovat strojov´ y ˇcas v´ıc, neˇz je nutné, 3 Xerox research internetwork byla poˇc´ıtaˇcov´ a s´ıt’ v r´ amci spoleˇcnosti Xerox, kter´ a slouˇzila zejména k v´ yzkumu nov´ ych technologi´ı v IT oblasti. Systém Grapevine [10] pak nab´ızel prostˇredky napˇr´ıklad pro pouˇzit´ı e-mailu, autentikace ˇci pr´ avˇe vzd´ aleného vol´ an´ı metod.


8

∙ v neposledn´ı ˇradˇe pak mˇela implementace umoˇznit zabezpeˇcenou komunikaci mezi volaj´ıc´ım a volan´ ym poˇc´ıtaˇcem. V´ yvojáˇri z Xerox Research Center vˇsak museli vyˇreˇsit následuj´ıc´ı problémy: ∙ sémantika v pˇr´ıpadˇe selh´ an´ı komunikace nebo algoritmu (napˇr. dead-lock), ∙ sémantika pˇri nalezen´ı argumentu procedury obsahuj´ıc´ım odkaz na adresn´ı prostor, kter´ y nemus´ı existovat, ∙ zaˇclenˇen´ı RPC mechanismu do aplikac´ı, ∙ jak´ ym zp˚ usobem zjist´ı volaj´ıc´ı poˇc´ıtaˇc um´ıstˇen´ı (z dneˇsn´ıho pohledu IP adresu) poˇc´ıtaˇce volaného, ∙ vhodné protokoly pro pˇrenos dat mezi poˇc´ıtaˇci, ∙ zajiˇstˇen´ı bezpeˇcnosti pˇri vol´ an´ı procedur. V následuj´ıc´ım textu postupnˇe objasn´ıme ˇreˇsen´ı nˇekter´ ych z uveden´ ych problém˚ u. 2.2.3.1

N´ avrh komponent RPC syst´ emu

Obrázek 2.2 popisuje jednotlivé komponenty RPC systému a jejich vzájemnou komunikaci. Na stranˇe volaj´ıc´ıho poˇc´ıtaˇce (d´ ale jen klienta) jsou to: ∙ User - uˇzivatel/program volaj´ıc´ı vzdálenou proceduru, ∙ User-stub - komponenta zajiˇst’uj´ıc´ı operaci s argumenty (z dneˇsn´ıho pohledu ˇreknˇeme serializaci a deserializaci4 , kter´ a nav´ıc obsahuje interface se specifikac´ı vzdálené procedury, ∙ jedna instance RPC communications package (RPCRuntime) - bal´ıˇcek, kter´ y se stará o spolehliv´ y pˇrenos dat mezi poˇc´ıtaˇci (dnes k tomu vyuˇz´ıváme protokol TCP/IP5 zajiˇst’uj´ıc´ı mimo jiné pr´ avˇe spolehliv´ y pˇrenos dat) a ˇsifrován´ı komunikace. A na stranˇe volaného poˇc´ıtaˇce (d´ ale jen serveru) se nacházej´ı tyto komponenty: ∙ Server - poˇc´ıtaˇc zajiˇst’uj´ıc´ı samotn´ y v´ ypoˇcet procedury, ∙ Server-stub - komponenta s podobnou funkc´ı jako user-stub, ∙ jedna instance RPCRuntime. Komponenty User-stub a Server-stub jsou generovány automaticky, naopak User a Server ˇ obsahuj´ı kód vytvoˇren´ y program´ atorem vyv´ıjej´ıc´ım distribuovanou aplikaci. Cervenˇ e jsou na obrázku 2.2 vyznaˇceny operace, které by probˇehly, pokud by byla volána lokáln´ı procedura nam´ısto vzdálené. Pokud chce uˇzivatel resp. program zavolat vzdálenou proceduru, probˇehne nejprve 4 Serializace je zp˚ usob pˇreveden´ı objektu na sekvenci byt˚ u (paket˚ u), které pak mohou b´ yt pˇreneseny pˇres s´ıt’. Deserializace je pˇresnˇe opaˇcn´ y postup. 5 Protokol TCP/IP nab´ız´ı spolehliv´ y plnˇe duplexn´ı pˇrenos dat mezi dvˇema poˇc´ıtaˇci [11].

2.2. HISTORIE

9

Caller machine User local call

User-stub pack arg.

Network

RPCRuntime transmit wait

local result

unpack result

Call packet

receive

Callee machine RPCRuntime Server-stub receive

unpack arg.

Server call work

Result packet transmit

importer exporter interface

pack result

return

importer exporter interface

Obrázek 2.2: Komponenty RPC systému v implementaci v rámci Xerox research internetwork a jejich vz´ ajemn´ a komunikace. Obrázek je pˇrevzat´ y z [9] a zámˇernˇe je ponechán v angliˇctinˇe z d˚ uvodu pouˇzit´ı zavedené anglické terminologie. 1. standardn´ı vol´ an´ı odpov´ıdaj´ıc´ı lokáln´ı procedury v User-stub, 2. kter´ y d´ ale zajist´ı vytvoˇren´ı jednoho nebo v´ıce paket˚ u obsahuj´ıc´ıch definici procedury spolu s jej´ımi argumenty, 3. RPCRuntime v klientském poˇc´ıtaˇci odeˇsle pakety serveru, 4. kde je opˇet RPCRuntime pˇrijme a pˇredá data do Server-stub. 5. Server-stub provede deserializaci argument˚ u a standardnˇe zavolá odpov´ıdaj´ıc´ı lok´ aln´ı proceduru na serveru. Mezit´ım je proces na klientském poˇc´ıtaˇci pozastaven a ˇcek´ a na v´ ysledky. 6. Po vykon´ an´ı procedury nastane pˇresnˇe opaˇcn´ y proces, v´ ysledky jsou serializov´ any v Server-stub, 7. pomoc´ı RPCRuntime pˇreneseny do klientského poˇc´ıtaˇce (pozastaven´ y proces je opˇet spuˇstˇen), 8. kde je User-stub deserializuje a pˇredá uˇzivateli/programu. 2.2.3.2

S´ emantika v pˇ r´ıpadˇ e selh´ an´ı komunikace ˇ ci algoritmu

Bylo d˚ uleˇzité rozhodnout, s jakou sémantikou se bude provádˇet vzdálené volán´ı procedur v pˇr´ıpadˇe r˚ uzn´ ych selh´ an´ı. Implementace dle [9] vycház´ı z jiˇz v´ yˇse zm´ınˇeného faktu, ˇze je nejjednoduˇsˇs´ı a nejlogiˇctˇejˇs´ı, aby se vzdálené procedury chovaly stejnˇe jako ty lokáln´ı. Pro program´ atora je tato situace ide´ aln´ı. Rozliˇs´ıme tedy tyto pˇr´ıpady selhán´ı: 1. pokud selˇ ze komunikace mezi poˇ c´ıtaˇ ci (napˇr. pˇri nenalezen´ı odpov´ıdaj´ıc´ıho serveru, kter´ y by vzd´ alenˇe vykonal proceduru), RPCRuntime se postará o proveden´ı odpov´ıdaj´ıc´ıch akc´ı. Znamen´ a to, ˇze klientsk´ y program se dozv´ı o chybˇe komunikace (odpov´ıdaj´ıc´ı v´ yjimkou) a m˚ uˇze na tuto událost zareagovat,


10

2. v pˇr´ıpadˇe selh´ an´ı algoritmu a vyhozen´ı v´ yjimky je tato v´ yjimka propagována do klientského programu, kde je obslouˇzena, 3. pokud vˇsak algoritmus selˇ ze z d˚ uvodu chybn´ eho k´ odu (napˇr. dead-lock, zacyklen´ı), ˇzádná v´ yjimka nen´ı vyhozena a volaj´ıc´ı program/uˇzivatel tuto chybu nepozná. Toto chován´ı je totoˇzné s chov´ an´ım lok´ aln´ı procedury. 2.2.3.3

Zajiˇ stˇ en´ı bezpeˇ cnosti komunikace

V´ yˇse popisovan´ a implementace byla prvn´ı, která nab´ıdla prostˇredky pro bezpeˇcnou komunikaci dvou poˇc´ıtaˇc˚ u pomoc´ı RPC. Volaj´ıc´ı poˇc´ıtaˇc mˇel tak jistotu, ˇze server je opravdu ten, za kterého se vyd´ av´ a, a naopak. Tuto autentizaci zajiˇst’oval systém Grapevine [10] v rámci Xerox research internetwork. Tato RPC knihovna nav´ıc nab´ızela podporu pro celkové ˇsifrován´ı volán´ı i v´ ysledk˚ u procedur. Dalo se tedy jednoduˇse zabr´ anit napˇr´ıklad zmˇenˇe volané procedury u ´toˇcn´ıkem.

2.2.4

Dalˇ s´ı v´ yvoj RPC

Nyn´ı se zamˇeˇrme na dalˇs´ı historick´ y v´ yvoj vzdáleného volán´ı procedur a zmiˇ nme nejd˚ uleˇzitˇejˇs´ı implementace ˇci protokoly vych´ azej´ıc´ı z RPC, které byly v pr˚ ubˇehu ˇcasu vytvoˇreny. Nejznámˇejˇs´ı implementace a nové protokoly, které se pouˇz´ıvaj´ı dnes, vˇsak pop´ıˇseme aˇz v ˇcásti 2.4. 2.2.4.1

Sun Microsystems

D˚ uleˇzit´ ym hráˇcem v oblasti vzd´ aleného volán´ı procedur byla firma Sun Microsystems. Ve stejném roce, kdy byla pops´ ana prvn´ı implementace RPC (1984), vyvinula tato firma protokol Network File System, kter´ y umoˇzn ˇoval pˇr´ıstup k soubor˚ um na vzdáleném poˇc´ıtaˇci v systému ˇ Unix. Cást, kter´ a zajiˇst’ovala samotnou komunikaci mezi poˇc´ıtaˇci, se naz´ yvala Sun’s RPC. Dnes má tento systém n´ azev Open Network Computing Remote Procedure Call a je to, dalo by se ˇr´ıci, základn´ı popsan´ y standard vzdáleného volán´ı procedur. Od roku 1988 pak Sun Microsystems vydává dokumenty RFC popisuj´ıc´ı tento protokol. Uved’me si nyn´ı, jak byly tyto dokumenty postupnˇe zveˇrejˇ novány. ∙ RFC 1050 (1988) [79] - jak jsme jiˇz zm´ınili v ˇcásti 2.1, prvn´ım dokumentem popisuj´ıc´ım specifikaci protokolu bylo RFC 1050 z roku 1988. ∙ RFC 1057 (1988) [80] - jen o nˇekolik mˇes´ıc˚ u pozdˇeji byl vˇsak vydán nov´ y dokument, kter´ y popisoval druhou, vylepˇsenou verzi protokolu. ∙ RFC 1831 (1995) [75] - v roce, kdy byl také pˇredstaven programovac´ı jazyk Java, byla zveˇrejnˇena nov´ a specifikace RPC. Od té z roku 1988 se vˇsak nijak zásadnˇe neliˇsila, byla sp´ıˇse zjednoduˇsena. V oblasti bezpeˇcnosti (autentizace) byly napˇr´ıklad odebrány nˇekteré moˇznosti, které v tu dobu jiˇz nemohly b´ yt pouˇzity, protoˇze vyuˇz´ıvaly zastaralé techniky.

ˇ Í VYZNAM ´ ´ ´ ´ Í PROCEDUR 2.3. DNESN VZDALEN EHO VOLAN

11

∙ RFC 5531 (2009) [82] - aktuáln´ı specifikace z roku 2009 reflektuje v novém dokumentu zmˇeny, které se ud´ aly v oblasti internetu. Vˇetˇsina tˇechto zmˇen se t´ yká opˇet bezpeˇcnosti, ale také napˇr´ıklad specifikace formátu popisuj´ıc´ı vzdálenou proceduru. Tento z´ apis vyuˇz´ıv´ a tzv. External Data Representation Standard (XDR) [29], kter´ y doznal od roku 1995 nˇekolika zmˇen. 2.2.4.2

Ostatn´ı firmy

Nebyla to vˇsak jen firma Sun Microsystems, která vytváˇrela implementace a standardy v oblasti RPC. Spoleˇcnost Apollo Computer vytvoˇrila v osmdesát´ ych letech Network Computing System (NCS), coˇz byla implementace vzdáleného volán´ı procedur. NCS pozdˇeji slouˇzil jako z´ aklad pro DCE/RPC, tedy Distributed Computing Environment / Remote Procedure Calls. V roce 1989 vytvoˇrily firmy Hewlett-Packard, IBM, Sun Microsystems, Apple Computer, American Airlines a Data General uskupen´ı Object Management Group, které v ˇr´ıjnu roku 1991 pˇredstavilo prvn´ı verzi protokolu CORBA [8], kter´ y je velmi známou implementac´ı nebo sp´ıˇse nov´ ym protokolem vycházej´ıc´ım z RPC. V´ıce se o tomto protokolu a o tom, proˇc nakonec nebyl u ´spˇeˇsn´ y, doˇctete v ˇcásti 2.4. Pozdˇeji vstupuje do hry i Microsoft, kter´ y vyvine sv˚ uj protokol DCOM (postaven´ y na RPC) [1] pro vzd´ alenou komunikaci komponent ve Windows. V´ıce o tomto protokolu v ˇcásti 2.4.

2.3

Dneˇ sn´ı v´ yznam vzd´ alen´ eho vol´ an´ı procedur

Vzdálené vol´ an´ı procedur se i dnes stále pouˇz´ıvá ke komunikaci pˇri distribuovan´ ych v´ ypoˇctech, jeho v´ yznam vˇsak roste v jin´ ych oblastech.

2.3.1

Rich Internet Applications

Pˇricház´ıme do doby, kdy klasické desktopové aplikace zaˇc´ınaj´ı b´ yt pomalu, ale jistˇe vytlaˇcovány tˇemi internetov´ ymi. M˚ uˇzeme tak mluvit o tzv. Rich Internet Applications (RIA), coˇz bychom mohli pˇreloˇzit jako plnohodnotné internetové aplikace, tedy takové, které nab´ız´ı podobné funkce, na které jsme zvykl´ı z aplikac´ı desktopov´ ych [13]. Ze zástupc˚ u RIA aplikac´ı jmenujme napˇr´ıklad: ∙ Gmail - webov´ y e-mail, ∙ Photoshop Express - editor fotografi´ı, ∙ Docs - webov´ a verze program˚ u Microsoft Word, Excel a PowerPoint. Kaˇzd´ a ze zm´ınˇen´ ych aplikac´ı s nejvˇetˇs´ı pravdˇepodobnost´ı vyuˇz´ıvá nˇejakou implementaci RPC (s u ´plnou jistotou to samozˇrejmˇe nelze ˇr´ıci, protoˇze kód tˇechto aplikac´ı nen´ı veˇrejnˇe pˇr´ıstupn´ y, ale z vlastn´ıch zkuˇsenost´ı to pˇredpokládám). Klientem je v tomto pˇr´ıpadˇe internetov´ y prohl´ıˇzeˇc, kter´ y zobrazuje prezentaˇcn´ı vrstvu aplikace a komunikuje s aplikaˇcn´ı logikou um´ıstˇenou na serveru pr´ avˇe pomoc´ı RPC.


12

Je zˇrejmé, ˇze tento trend se bude jeˇstˇe prohlubovat a moˇzná se jednou doˇckáme chv´ıle, kdy budou poˇc´ıtaˇce jen jakési internetové terminály. T´ımto smˇerem se napˇr´ıklad vydává operaˇcn´ı systém Chrome OS od firmy Google. V posledn´ıch letech nav´ıc pˇrich´ azej´ı na trh mobiln´ı telefony, které sv´ ym v´ ykonem pˇrevyˇsuj´ı dˇr´ıvˇejˇs´ı poˇc´ıtaˇce. Tyto mobiln´ı telefony nav´ıc disponuj´ı rychl´ ym internetov´ ym pˇripojen´ım, takˇze pro uˇzivatele nen´ı problém s internetem pracovat podobn´ ym zp˚ usobem jako na poˇc´ıtaˇci. Vzhledem k tomu, ˇze velké vyt´ıˇzen´ı procesoru telefonu pomˇernˇe hodnˇe spotˇrebovává energii (a tud´ıˇz sniˇzuje v´ ydrˇz baterie), je v pˇr´ıpadˇe nároˇcn´ ych v´ ypoˇct˚ u lepˇs´ı tyto provést na vzdáleném serveru a do telefonu poslat jen v´ ysledek. Opˇet se v tomto pˇr´ıpadˇe s nejvˇetˇs´ı pravdˇepodobnost´ı pouˇzije vzd´ alené zavolán´ı procedury a mobiln´ı klient m˚ uˇze b´ yt dokonce pouze optimalizovan´ a verze RIA aplikace.

2.3.2

Software jako sluˇ zba

S protokolem RPC u ´zce souvis´ı pojem Software jako sluˇzba“ (z anglického Software as ” ” a service“ - zkratka SaaS). Je to zp˚ usob poskytován´ı softwaru jakoˇzto sluˇzby na internetu. A vˇetˇsina tˇechto sluˇzeb pouˇz´ıv´ a ke komunikaci s klientem právˇe nˇejakou formu vzdáleného volán´ı procedur.

Poskytovatel služby Publikování služby

Klient – server komunikace

Registr služeb

Klient Nalezení služby

Obrázek 2.3: Architektura nasazen´ı softwaru jako sluˇzby. Obrázek je pˇrevzat´ y z [63]. P˚ uvodn´ı koncepce softwaru jako sluˇzby se vˇsak jist´ ym zp˚ usobem liˇs´ı od té dneˇsn´ı. Sluˇzbou se rozumˇela sp´ıˇse jednoduˇsˇs´ı funkce (jmenujme napˇr´ıklad sluˇzbu pro pˇrepoˇcet mˇeny), jej´ıˇz definice byla uloˇzena v nˇejakém centr´ aln´ım registru sluˇzeb a kdokoliv ji mohl vyuˇz´ıt. Tuto architekturu zobrazuje obr´ azek 2.3. Poskytovatel v této architektuˇre nab´ız´ı definici sluˇzby za pouˇzit´ı protokolu WSDL [87]. Komunikace mezi klientem a serverem je pak zajiˇstˇena pomoc´ı protokolu SOAP (v´ıce se o tomto protokolu doˇctete v ˇcásti 2.4). Sluˇzba m˚ uˇze b´ yt pouˇzita: ∙ samotn´ ym klientem (napˇr´ıklad aplikac´ı pro pˇrepoˇcet mˇeny, která ke svému chodu vyuˇz´ıvá nˇekterou webovou sluˇzbu poskytuj´ıc´ı pˇrevod mˇen) nebo

´ ÍCÍ Z RPC 2.4. DALSˇÍ TECHNOLOGIE A PROTOKOLY VYCHAZEJ

13

∙ jinou sluˇzbou. Webové sluˇzby dle p˚ uvodn´ıho konceptu by pak mˇely b´ yt [63]: ∙ platformˇ e nez´ avisl´ e - mus´ı je b´ yt moˇzno zavolat pˇres standardn´ı protokoly, které jsou nez´ avislé na poˇc´ıtaˇcové platformˇe, ∙ oddˇ elen´ e od implementace - nem˚ uˇze b´ yt vyˇzadována znalost jak´ ychkoli vnitˇrn´ıch struktur (implementace) sluˇzby, pokud ji chceme pouˇz´ıt, ∙ nez´ avisl´ e na um´ıstˇ en´ı - definice sluˇzeb mus´ı b´ yt uloˇzena v nˇejakém centráln´ım registru a um´ıstˇen´ı samotné sluˇzby nem˚ uˇze hrát pro klienta roli. Nen´ı pravda, ˇze by se v´ yˇse zm´ınˇen´ y zp˚ usob dnes jiˇz nepouˇz´ıval, ale s rozvojem rychlého internetu se postupnˇe pojem Software as a service“ zaˇcal pouˇz´ıvat v trochu odliˇsné ” souvislosti [26][39]. Pokud dnes firmy pouˇz´ıvaj´ı software jako sluˇzbu, je t´ım myˇsleno, ˇze si nenakupuj´ı klasick´ y software, kter´ y se mus´ı instalovat na poˇc´ıtaˇc, ale pouˇz´ıvaj´ı webové aplikace (mohou to b´ yt RIA aplikace) poskytuj´ıc´ı stejné funkce. Jako v´ yhody tohoto provozován´ı softwaru m˚ uˇzeme uvést: ∙ niˇzˇs´ı poˇrizovac´ı n´ aklady, ∙ odpad´ a nutnost provozu technické podpory (software nen´ı hostován na naˇsem serveru, takˇze se o technické zajiˇstˇen´ı stará dodavatelská spoleˇcnost), ∙ v r´ amci jedné ceny m´ ame vˇetˇsinou pˇr´ıstup vˇzdy k nejnovˇejˇs´ım verz´ım softwaru, tyto verze se nav´ıc aktualizuj´ı automaticky. Mezi nev´ yhody naopak patˇr´ı napˇr´ıklad: ∙ potencion´ aln´ı bezpeˇcnostn´ı riziko - data firmy jsou uloˇzena u tˇret´ı spoleˇcnosti, nicménˇe je dnes bˇeˇzné, ˇze spoleˇcnosti provozuj´ıc´ı software jako sluˇzbu maj´ı svoje servery zabezpeˇceny v´ yraznˇe v´ıc, neˇz samotné firmy, ∙ obt´ıˇzné uzp˚ usoben´ı softwaru individuáln´ım potˇrebám zákazn´ıka - vzhledem k tomu, ˇze se v naprosté vˇetˇsinˇe jedn´ a o webové aplikace poskytované mnoha zákazn´ık˚ um zároveˇ n, nen´ı moˇzné splnit vˇsechny jejich individuáln´ı poˇzadavky.

2.4

Dalˇ s´ı technologie a protokoly vych´ azej´ıc´ı z RPC

Specifikace protokolu RPC je velmi obecná, proto byly postupnˇe vytvoˇreny urˇcité nadstavby ˇ - tedy dalˇs´ı protokoly - vych´ azej´ıc´ı ze vzdáleného volán´ı procedur. Casto se vˇsak bohuˇzel zamˇen ˇuje teoretick´ y problém (vzd´ alené volán´ı procedur) s jeho realizac´ı (implementace RPC). Setk´ av´ ame se s t´ım, ˇze implementace protokolu RPC je oznaˇcena za nov´ y protokol (napˇr. XML-RPC) nebo naopak, ˇze protokol vycházej´ıc´ı z RPC je oznaˇcen pouze za jeho implementaci.


14

Osobnˇe si mysl´ım, ˇze napˇr´ıklad XML-RPC je pouze implementac´ı RPC, která definuje zp˚ usob komunikace dvou poˇc´ıtaˇc˚ u a form´ at zpráv, které si vymˇen ˇuj´ı. Naopak protokol REST je dle mého názoru jiˇz nadstavbov´ y protokol postaven´ y na RPC, protoˇze definuje speciáln´ı poˇzadavky na komunikaci klienta a serveru, které samotn´ y protokol RPC nevyˇzaduje. Postupnˇe si nyn´ı pop´ıˇseme nejd˚ uleˇzitˇejˇs´ı nadstavbové protokoly6 vycházej´ıc´ı z RPC. V´ yjimku udˇeláme u technologie Java RMI, pro kterou vyˇclen´ıme zvláˇstn´ı podkapitolu, protoˇze tuto technologii budeme pouˇz´ıvat (dle zadán´ı) v naˇsem informaˇcn´ım systému, bude tedy vhodné ji popsat podrobnˇeji. XML-RPC Jak uˇz n´ azev napov´ıd´ a, XML-RCP [53][90] je protokol vyuˇz´ıvaj´ıc´ı XML7 ke 8 kódován´ı zpráv a HTTP ke komunikaci mezi klientem a serverem. Nem˚ uˇzeme mluvit vyloˇzenˇe o nové technologii postavené na RPC, ale sp´ıˇse o specifikaci, jak´ ym zp˚ usobem spolu komunikuj´ı dva poˇc´ıtaˇce. Pˇr´ıklad poˇzadavku XML-RPC vol´ an´ı: 1 2 3 4 5 6 7 8

<methodCall> <methodName>helloWorld.hello <params> <param> <string>John Pˇr´ıklad odpovˇedi od serveru:

1 2 3 4 5 6 7

<methodResponse> <params> <param> <string>Hello, John. U volán´ı ani u odpovˇedi jsme pro pˇrehlednost neuvádˇeli HTTP hlaviˇcku, která mus´ı b´ yt samozˇrejmˇe souˇc´ ast´ı zpr´ avy, protoˇze je pouˇzit protokol HTTP. Protokol XML-RPC jiˇz nen´ı nad´ ale vyv´ıjen a nahradil ho protokol SOAP, kter´ y z nˇeho vycház´ı. 6

Nadstavbov´ ymi protokoly tedy mysl´ıme i implementace RPC, které jsou vˇsak naz´ yv´ any samostatn´ ymi protokoly. 7 Extensible Markup Language (zkratka XML) je znaˇckovac´ı jazyk pouˇz´ıvan´ y ke k´ odov´ an´ı zpr´ av. Je velmi dobˇre ˇciteln´ y pro ˇclovˇeka, avˇsak pr´ avˇe proto je jeho zpracov´ an´ı poˇc´ıtaˇcem pomalejˇs´ı neˇz napˇr´ıklad konkurenˇcn´ıho jazyka JSON. 8 HTTP je internetov´ y protokol, kter´ y slouˇz´ı k v´ ymˇenˇe hypertextov´ ych dokument˚ u.


15

Simple Object Access Protocol (SOAP) Protokol SOAP [72][88] byl p˚ uvodnˇe vytvoˇren firmami Microsoft, Userland Software a IBM. V roce 2006 dokonce z´ıskali zakladatelé na protokol SOAP patent [58]. Specifikace protokolu je vˇsak nyn´ı spravována World Wide Web konsorciem. Na rozd´ıl od protokolu XML-RPC specifikace SOAP povoluje komunikaci také pomoc´ı pos´ılán´ı zpr´ av nam´ısto RPC. Ostatn´ı technologie jsou totoˇzné, liˇs´ı se pouze syntaxe vol´ an´ı a odpovˇed´ı. Strukturu XML zpr´ avy zobrazuje obrázek 2.4.

SOAP Envelope

SOAP Header

SOAP Body

Obr´ azek 2.4: Struktura XML zprávy protokolu SOAP. V XML zpr´ avˇe SOAP se tedy nacházej´ı tyto ˇcásti: ∙ Envelope (ob´ alka) - definuje základn´ı prvky zprávy a celou ji obaluje, ∙ Header (hlaviˇcka) - tato nepovinná ˇcást m˚ uˇze obsahovat napˇr´ıklad kódován´ı zpr´ avy, definici datov´ ych typ˚ u a podobnˇe, ∙ Body (tˇelo) - obsahuje samotné RPC volán´ı nebo odpovˇed’. Nyn´ı si uvedeme pˇr´ıklad SOAP volán´ı. Odpovˇed’ od serveru uvádˇet nebudeme, liˇs´ı se pouze v pˇrid´ an´ı slova Response“ za název metody. V naˇsem pˇr´ıpadˇe by tedy nam´ısto ” zde bylo: . 1 2

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">


16

3 4 5 6 7 8

<SOAP-ENV:Body> John Jak bylo zm´ınˇeno v ˇc´ asti 2.3.2, protokol SOAP se vyuˇz´ıvá pˇreváˇznˇe pro webové sluˇzby. Jeho v´ yhoda je zejména v moˇznosti pouˇzit´ı na r˚ uzn´ ych platformách a jednoduchosti implementace. Stejnˇe jako u protokolu XML-RPC, ze kterého vycház´ı, nen´ı SOAP omezen napˇr´ıklad firewally, protoˇze pouˇz´ıv´ a na u ´rovni aplikaˇcn´ı vrstvy HTTP. Jako nejvˇetˇs´ı nev´ yhodu uved’me niˇzˇs´ı rychlost z d˚ uvodu velké komunikaˇcn´ı reˇzie (zprávy jsou pˇrehledné a ˇcitelné pro ˇclovˇeka, ale poˇc´ıtaˇc takto strukturované XML mus´ı parsovat a je to v´ yraznˇe pomalejˇs´ı neˇz kdyby pˇrijal binárn´ı zprávu). Tato nev´ yhoda vˇsak ˇcásteˇcnˇe odpadá pˇri pos´ılán´ı vˇetˇs´ıch zpr´ av, kdy vˇetˇsinu zprávy zab´ıraj´ı parametry (nebo návratová hodnota). JSON-RPC Protokol JSON-RPC se od pˇredchoz´ıch dvou liˇs´ı pouze notac´ı pouˇzitou ke kódován´ı zpráv. Nepouˇz´ıv´ a XML, ale tzv. JavaScript Object Notation (JSON) [18][49]. Z názvu by se mohlo zd´ at, ˇze je tento form´ at urˇcen pouze pro zpracován´ı v programovac´ım jazyku JavaScript, avˇsak nen´ı to pravda, je to platformˇe nezávisl´ y formát pro pˇrenos dat. Dalo by se ˇr´ıci, ˇze JSON je odlehˇcenou variantou XML, protoˇze klade d˚ uraz na minimalizaci znak˚ u potˇrebn´ ych pro definov´ an´ı struktury zprávy. Mezi podporované datové typy patˇr´ı: ∙ pole, ∙ objekty a ∙ samostatné hodnoty (ˇretˇezce ˇci ˇc´ısla). Následuj´ıc´ı zápis pˇredstavuje uk´ azku zakódován´ı objektu Product:

1 2 3 4 5

{"product": { "name": "Bike", "id": "457", "price": 52.5 }} Representational State Transfer (REST) Technologie REST byla navrˇzena R. Fieldingem v jeho disertaci [30] jako standard pro komunikaci poˇc´ıtaˇc˚ u v distribuovaném prostˇred´ı. Podobnˇe jako XML-RPC resp. SOAP má i protokol REST nejvˇetˇs´ı vyuˇzit´ı v oblasti ˇ webov´ ych sluˇzeb [43]. Casto se setk´ av´ ame s pojmem RESTful API, coˇz je jen pojmenován´ı 9 API vyuˇz´ıvaj´ıc´ıho protokolu REST. 9

Application Programming Interface (zkr´ acenˇe API) je rozhran´ı, které poskytuje dan´ y program, sluˇzba ˇci protokol a jehoˇz metody pak m˚ uˇze program´ ator vyuˇz´ıvat.


17

V´ yˇse zm´ınˇené protokoly pouˇz´ıvaj´ı ke komunikaci formu RPC. Dalo by se ˇr´ıci, ˇze REST také vyuˇz´ıv´ a z´ akladu ze vzd´ aleného volán´ı procedur, avˇsak komunikace je orientována datovˇe, máme totiˇz na v´ ybˇer pouze ˇctyˇri metody [56][43]. Tyto metody definuj´ı základn´ı operace s daty, tedy tzv. soubor operac´ı CRUD (Create - vytvoˇren´ı, Retrieve - z´ıskán´ı, Update aktualizace a Delete - smaz´ an´ı) a vycházej´ı z metod protokolu HTTP. ∙ GET (Retrieve) - z´ısk´ an´ı seznamu poloˇzek ˇci zobrazen´ı informac´ı o konkrétn´ı poloˇzce (HTTP metoda GET), ∙ PUT (Update) - aktualizace celého seznamu poloˇzek nov´ ym seznamem ˇci aktualizace jedné konkrétn´ı poloˇzky; v pˇr´ıpadˇe, ˇze tato poloˇzka neexistuje, je vytvoˇrena (HTTP metoda POST), ∙ POST (Create) - vytvoˇren´ı nové poloˇzky (HTTP metoda POST), ∙ DELETE - smaz´ an´ı jedné konkrétn´ı poloˇzky ˇci celého seznamu poloˇzek (HTTP metoda DELETE). RESTful API pouˇz´ıv´ a napˇr´ıklad známá sluˇzba Twitter.com. Pro z´ıskán´ı zpráv konkrétn´ıho uˇzivatele zavol´ ame n´ asleduj´ıc´ı: GET /statuses/user_timeline/uzivatel.xml Host: twitter.com Common Object Request Broker Architecture (CORBA) Tento protokol vznikl jiˇz na zaˇc´ atku devades´ at´ ych let minulého stolet´ı. Narozd´ıl od pˇredchoz´ıch vyuˇz´ıvá pro pˇrenos dat protokolu TCP/IP a ne HTTP. Protokol HTTP totiˇz teprve vznikal, kdyˇz byla pˇredstavena verze CORBA 1.0. Protokol CORBA je nadstavbou RPC, kdy pro definici procedur vyuˇz´ıvá tzv. Interface definition language, coˇz je standard pro zápis rozhran´ı slouˇz´ıc´ıho pro komunikaci r˚ uzn´ ych komponent programu napsan´ ych v rozd´ıln´ ych programovac´ıch jazyc´ıch [8]. Pr´ avˇe usnadnˇen´ı komunikace r˚ uzn´ ych komponent systému bylo hlavn´ım c´ılem tohoto protokolu. Mnoho ˇc´ ast´ı specifikace protokolu vˇsak nebylo v˚ ubec nikdy implementováno a dnes se protokol pouˇz´ıv´ a sp´ıˇse zˇr´ıdka. Problém byl v dobˇe vzniku protokolu zejména ve sloˇzitosti specifikace a v absenci jakékoli re´ alné (byt’ jen ukázkové) implementace, která by poskytovala pˇr´ıklad pouˇzit´ı [36]. Distributed Component Object Model (DCOM) Dalˇs´ım protokolem zaloˇzen´ ym na RPC je propriet´ arn´ı systém spoleˇcnosti Microsoft - Distributed Component Object Model. Protokoly DCOM a CORBA b´ yvaj´ı ˇcasto porovnávány (napˇr. v [16]) a dalˇs´ım d˚ uvodem, proˇc nebyl protokol CORBA pˇr´ıliˇs u ´spˇeˇsn´ y bylo právˇe rozhodnut´ı Microsoftu o vytvoˇren´ı vlastn´ıho ˇreˇsen´ı. DCOM vych´ az´ı z protokolu COM (Component Object Model), coˇz je systém pro snadnou komunikaci r˚ uzn´ ych komponent v operaˇcn´ım systému Windows. Nejvˇetˇs´ı v´ yhoda tohoto systému spoˇc´ıv´ a v tom, ˇze mohou b´ yt jednotlivé komponenty odpojeny a nahrazeny za jiné bez nutnosti opˇetovné kompilace programu [1]. Na obr´ azku 2.5 vid´ıme architekturu protokolu DCOM. Zmiˇ nme nˇekteré jej´ı ˇcásti:


18

Klient

COM run-time Security Provider

COM run-time

DCE RPC

Protocol Stack

Security Provider

Komponenta

DCE RPC

Protocol Stack

DCOM network protocol

Obr´ azek 2.5: Architektura protokolu DCOM. Obrázek je pˇrevzat´ y z [1]. ∙ Klient - program, kter´ y chce vyuˇz´ıt nˇejakou vzdálenou komponentu, ∙ COM run-time - komunikaˇcn´ı prostˇred´ı protokolu COM, ∙ DCE RPC10 - komponenta, kter´ a zajiˇst’uje vzdálené volán´ı procedur. .NET Remoting V roce 2002 byla pˇredstavena spoleˇcnost´ı Microsoft prvn´ı verze frameworku11 .NET, kter´ y se od té doby pouˇz´ıvá k programován´ı aplikac´ı pod Windows. Protokol .NET Remoting navazuje na DCOM a je souˇcást´ı tohoto frameworku. Apache Thrift Protokol Thrift byl vyvinut primárnˇe pro stránku www.facebook.com pro vyuˇzit´ı distribuovan´ ych prostˇredk˚ u napˇr´ıˇc r˚ uzn´ ymi platformami (C++, Java, PHP a dalˇs´ı). Dnes je tento protokol uvolnˇen jako open-source skupinou Apache Software Foundation [68]. Definice urˇcité sluˇzby (implementované na jakékoli podporované platformˇe) v protokolu Thrift má následuj´ıc´ı formu: 1 2 3 4 5 6

service { (<arguments>) [throws (<exceptions>)] ... }

10

Jak jsme zm´ınili v ˇca ´sti 2.2.4.2, DCE RPC je zkratka pro Distributed Computing Environment / Remote Procedure Calls, coˇz je systém, kter´ y umoˇzn ˇuje pouˇzit´ı RPC v distribuovan´ ych prostˇred´ıch. 11 Framework m´ a v´ yznam urˇcité programové struktury ˇci n´ astroje, kter´ y pom´ ah´ a program´ atorovi ve v´ yvoji softwaru.


19

Jako pˇr´ıklad m˚ uˇzeme uvést tento zápis: 1 2 3 4 5 6

service StringCache { void set(1:i32 key, 2:string value), string get(1:i32 key) throws (1:KeyNotFound knf), void delete(1:i32 key) } Hessian Jedn´ a se o bin´ arn´ı protokol, kter´ y je tedy optimáln´ı pro pos´ılán´ı (velk´ ych) bin´ arn´ıch dat, coˇz nemus´ı b´ yt u ostatn´ıch RPC protokol˚ u pˇr´ıliˇs efektivn´ı. Hessian byl vytvoˇren spoleˇcnost´ı Caucho Technology, Inc. a dnes pro nˇej existuj´ı implementace pro ˇradu programovac´ıch jazyk˚ u (Java, Flash, Python, C++, .NET a dalˇs´ı) [37]. Burlap Tento protokol byl vytvoˇren pro snadnou komunikaci mezi webov´ ymi sluˇzbami. M˚ uˇze b´ yt dokonce pouˇzit ke komunikaci Enteprise Java Beans (EJB) se servery, které jsou postaveny na jiné platformˇe neˇz Java (se kterou EJB komponenty um´ı komunikovat nativnˇe). Ke kódov´ an´ı zpr´ av je pouˇzito XML. Protokol je velmi jednoduch´ y, proto je vhodn´ y k pouˇzit´ı napˇr´ıklad v mobiln´ıch telefonech [12]. GWT-RPC Protokol GWT-RPC je speciálnˇe vyvinut pro framework Google Web Toolkit, kter´ y usnadˇ nuje tvorbu RIA aplikac´ı (viz ˇcást 2.3.1). Oproti specifikaci RPC se vˇsak tento protokol liˇs´ı v jednom z´ asadn´ım bodˇe: komunikace se serverem prob´ıhá asynchronnˇe, GWTRPC totiˇz rozˇsiˇruje z´ akladn´ı zp˚ usob asynchronn´ı komunikace internetového prohl´ıˇzeˇce se serverem [24] [34]. Action Message Format (AMF) Tento binárn´ı formát se pouˇz´ıvá k serializaci objekt˚ u jazyka Action Script12 (podobnˇe jako se pouˇz´ıvá XML k serializaci objekt˚ u v protokolu XML-RPC). Do protokol˚ u vych´ azej´ıc´ıch z RPC jsme ho zaˇradili proto, ˇze komunikace Flash aplikac´ı se vzd´ alen´ ym serverem vyuˇz´ıvá RPC s t´ımto formátem. Existuj´ı implementace pro mnoho programovac´ıch jazyk˚ u jako napˇr. Java, .NET, PHP, Coldfusion a dalˇs´ı. Remote Python Call (RPyC) Tato knihovna je implementac´ı RPC v prostˇred´ı objektovˇe orientovaného programovac´ıho jazyka Python. Podporuje symetrickou komunikaci (jak klient, tak i server mohou pos´ılat dotazy) a synchronn´ı i asynchronn´ı volán´ı procedur [67]. PYthon Remote Objects (PYRO) Dalˇs´ı implementac´ı RPC v jazyce Python je systém PYthon Remote Objects. Je zde kladen d˚ uraz na jednoduchost a snadnost pouˇzit´ı. Distributed object system for Ruby (DRb) Dalˇs´ı objektovˇe orientovanou implementac´ı RPC je Distributed object system for Ruby. Tato knihovna slouˇz´ı pro komunikaci vzd´ alen´ ych objekt˚ u v programovac´ım jazyce Ruby [25]. 12

Action Script je programovac´ı jazyk pouˇz´ıvan´ y pˇri programov´ an´ı aplikac´ı na platformˇe Adobe Flash.


20

2.5

Java Remote Method Invocation

Pokud se dnes setk´ ame s pojmem Remote Method Invocation“ (dále jen RMI), je j´ım ve ” vˇetˇsinˇe pˇr´ıpad˚ u myˇslena implementace RPC v programovac´ım jazyku Java, tedy Java Re” mote Method Invocation“. V´ yznam tohoto term´ınu je vˇsak trochu obecnˇejˇs´ı. Vzdálené vol´ an´ı procedur se pouˇz´ıv´ a u neobjektov´ ych programovac´ıch jazyk˚ u, zat´ımco vzd´ alen´ ym vol´ an´ım metod se naopak mysl´ı objektovˇe orientovaná verze protokolu RPC. Je zˇrejmé, ˇze architektura RMI je oproti RPC o nˇeco sloˇzitˇejˇs´ı. Nejedná se totiˇz o prosté zavolán´ı vzdálené procedury, ale vˇse se odehrává v objektovˇe orientovaném prostˇred´ı. To vˇsak nemˇen´ı nic na tom, ˇze i RMI se snaˇz´ı programátorovi co nejv´ıce uˇsetˇrit práci a umoˇznit volán´ı vzdálené metody tak, jako by byla lokáln´ı. V dalˇs´ım textu budeme mluvit o technologii RMI a budeme j´ı myslet v´ yhradnˇe Java RMI, jak ji popisuje [44]. Ofici´ aln´ı white paper uvád´ı nˇekolik zásadn´ıch v´ yhod RMI oproti RPC. Je d˚ uleˇzité si uvˇedomit, ˇze RPC je platformˇ e nez´ avisl´ y protokol, coˇz je v´ yhoda, ale i nev´ yhoda. Pokud je jak´ ykoli protokol platformˇe nezávisl´ y, m˚ uˇzeme ho stejn´ ym zp˚ usobem pouˇz´ıvat na r˚ uzn´ ych platform´ ach (v r˚ uzn´ ych programovac´ıch jazyc´ıch). Znamená to vˇsak také, ˇze nem˚ uˇzeme vyuˇz´ıt vˇsech technologi´ı, které nab´ız´ı ten ˇci onen programovac´ı jazyk, ale mus´ıme pouˇz´ıvat technologie, které podporuj´ı vˇsechny platformy. Java RMI naopak plnˇe vyuˇz´ıv´ a vˇsech moˇznost´ı objektovˇe orientovaného programovac´ıho jazyku Java. Hlavn´ımi v´ yhodami RMI tedy jsou [44]: ∙ Objektovˇ e orientovan´ a technologie - moˇznost pˇrenáˇset jakékoli objekty, argumenty nejsou omezeny pouze na primitivn´ı datové typy tak, jak je tomu u RPC, ∙ Jednoduch´ a moˇ znost zmˇ eny implementace - nen´ı problém zmˇenit chován´ı aplikace tak, aby byla metoda (jej´ı implementace) vykonávána bud’ na serveru nebo na klientu. To, co m˚ uˇze vracet RMI metoda, m˚ uˇze b´ yt totiˇz objekt implementuj´ıc´ı dan´ y interface a samotn´ a operace m˚ uˇze b´ yt (pokud je to ˇzádouc´ı) vykonána na klientu (napˇr. z d˚ uvodu zabr´ anˇen´ı pˇrenosu velkého mnoˇzstv´ı dat, která by byla obsaˇzena v RMI volán´ı), ∙ Bezpeˇ cnost - je zajiˇstˇena bezpeˇcná komunikace mezi klientem a serverem, ∙ Jednoduch´ a struktura distribuovan´ eho programu - Java RMI nab´ız´ı jednoduch´ y zp˚ usob programov´ an´ı serverov´ ych i klientsk´ ych aplikac´ı, je pouˇzito standardn´ıch struktur, na které je program´ ator zvykl´ y (viz ˇcást 2.5.1), ∙ Pouˇ zit´ı nativn´ıch aplikac´ı - RMI m˚ uˇze komunikovat s nativn´ımi aplikacemi pomoc´ı Java Native Interface, nen´ı tedy nutné stávaj´ıc´ı serverové programy pˇrepisovat do jazyka Java, pokud jsou jiˇz vytvoˇrené v jiném jazyce (napˇr. v C++) a pˇritom vyuˇz´ıt vˇsech ostatn´ıch v´ yhod RMI.

2.5.1

Princip

Java RMI vych´ az´ı z protokolu RPC, za základn´ı princip m˚ uˇzeme tedy povaˇzovat ten, kter´ y jsme popsali v ˇc´ asti 2.1 resp. na obr´ azku 2.1. Samozˇrejmˇe s t´ım rozd´ılem, ˇze se na serveru nevykonávaj´ı procedury, ale metody [86].

2.5. JAVA REMOTE METHOD INVOCATION

21

Standardn´ı Java aplikace vˇzdy funguje pod jedn´ım virtuáln´ım strojem (Java Virtual Machine - JVM)13 . RMI umoˇzn ˇuje distribuovan´ y v´ ypoˇcet t´ım zp˚ usobem, ˇze je moˇzné jednotlivé metody vykon´ avat na r˚ uzn´ ych virtuáln´ıch stroj´ıch. Základn´ım kamenem Java RMI je rozhran´ı definuj´ıc´ı chován´ı volané metody. Je d˚ uleˇzité si uvˇedomit, ˇze vˇetˇsina v´ yhod RMI plyne právˇe z oddˇelen´ı rozhran´ı a implementace. Ze základn´ıch princip˚ u jazyka Java vˇsak plyne, ˇze pokud voláme metodu nˇejakého rozhran´ı v jednom JVM, mus´ı zde b´ yt také obsaˇzena implementace. Java RMI tento poˇzadavek ˇreˇs´ı tak, ˇze v klientském k´ odu je implementace daného rozhran´ı také obsaˇzena, je to vˇsak pouze tzv. zástupn´ y objekt (proxy)14 .

«interface» Service

Klient Service Proxy

Server

RMI komunikace

Service Implementace

Obrázek 2.6: Pouˇzit´ı n´ avrhového vzoru Proxy pˇri RMI komunikaci mezi klientem a serverem. Obrázek je pˇrevzat´ y z [66]. Na obr´ azku 2.6 je zobrazena komunikace pomoc´ı zástupného objektu. Klientsk´ y program tedy: 1. provede vol´ an´ı metody v proxy objektu, 2. RMI poˇsle poˇzadavek na vzdálen´ y server (jinému JVM), 3. zde se provede skuteˇcn´ a metoda na základˇe konkrétn´ı implementace a 4. v´ ysledky jsou posl´ any zpˇet pomoc´ı RMI klientskému proxy objektu a od nˇej pˇred´ any volaj´ıc´ımu programu. ˇ asti Klient“ Architektura Java RMI se skládá z nˇekolika vrstev, jak uvád´ı obrázek 2.7. C´ ” a Server“ na obr´ azku pˇredstavuj´ı komponenty, které jsou vytváˇreny programátorem, ˇc´ asti ” RMI systému jsou naopak vytv´ aˇreny bud’ automaticky nebo jsou souˇcást´ı JDK15 a programátor s nimi nepˇrijde do styku [40] [66]. 13 Java Virtual Machine (zkr´ acenˇe JVM) je virtu´ aln´ı procesor, na kterém bˇeˇz´ı zkompilované Java programy (tedy bytek´ od). JVM m´ a svoji vlastn´ı instrukˇcn´ı sadu a proto m˚ uˇze b´ yt programovac´ı jazyk Java platformˇe nez´ avisl´ y - v kaˇzdém operaˇcn´ım systému je spuˇstˇen pouze odliˇsn´ y virtu´ aln´ı stroj, ale zdrojov´ y k´ od programu potaˇzmo zkompilovan´ y bytek´ od je vˇzdy stejn´ y [52]. 14 V´ıce o n´ avrhovém vzoru Proxy se dozv´ıte v [31]. 15 JDK neboli Java Development Kit je soubor programovac´ıch n´ astroj˚ u od firmy Sun Microsystems pro v´ yvoj aplikac´ı na platformˇe Java.


22

Aplikace

Klient

Skeletons RMI systém

Server

Stubs

Remote Reference vrstva Transportní vrstva

Obr´ azek 2.7: Vrstevnat´ a architektura RMI. Obrázek je pˇrevzat´ y z [66]. Stub a Skeleton vrstva Tato vrstva RMI architektury je zaloˇzena na v´ yˇse popsaném návrhovém vzoru Proxy. V tomto pˇr´ıpadˇe je zástupn´ ym objektem (proxy) tzv. tˇr´ıda Stub na stranˇe klienta. Skeleton je pouze pomocná tˇr´ıda um´ıstˇená na serveru, která zajiˇst’uje komunikaci pomoc´ı RMI se Stub objektem. Tato tˇr´ıda tedy pˇrij´ımá parametry metody, volá konkrétn´ı implementaci na serveru a v´ ysledky pos´ılá zpˇet pˇres RMI Stub objektu. Od verze Java 2 (Java SE) se k nalezen´ı implementace metody pouˇz´ıvá reflexe, tˇr´ıda Skeleton tedy jiˇz nen´ı potˇreba. Remote Reference vrstva Je nutné definovat sémantiku samotné RMI komunikace, o to se stará tato vrstva. Jedn´ a se o zp˚ usob, jak´ ym mezi sebou komunikuj´ı Stub a Skeleton objekty. Stub objekt vol´ a speci´ aln´ı metodu invoke() ve tˇr´ıdˇe RemoteRef zajiˇst’uj´ıc´ı propojen´ı s objektem, kter´ y obsahuje implementaci vzdálené metody. Transportn´ı vrstva Pro spojen´ı dvou JVM se vyuˇz´ıvá tato vrstva. K pˇrenosu dat je pouˇzit protokol TCP/IP. Pokud jsou dva JVM spuˇstˇeny na stejném poˇc´ıtaˇci, je komunikace naprosto totoˇzn´ a jako v pˇr´ıpadˇe, ˇze jsou virtuáln´ı stroje spuˇstˇeny na vzdálen´ ych poˇc´ıtaˇc´ıch.

2.5.2

Pouˇ zit´ı RMI

V následuj´ıc´ım textu si uk´ aˇzeme jednoduch´ y pˇr´ıklad pouˇzit´ı RMI v pˇr´ıpadˇe, ˇze klient i server jsou spuˇstˇeny na jednom poˇc´ıtaˇci. Budeme muset vytvoˇrit nˇekolik komponent, které jsme si popsali v´ yˇse: ∙ rozhran´ı poskytuj´ıc´ı klient˚ um definici vzdálen´ ych metod, ∙ implementaci tohoto rozhran´ı na serverové stranˇe, ∙ Stub (a Skeleton) tˇr´ıdy, ∙ samotn´ y serverov´ ya ∙ klientsk´ y modul.

2.5. JAVA REMOTE METHOD INVOCATION

23

ˇ Reknˇ eme, ˇze chceme vytvoˇrit jednoduchou distribuovanou“ aplikaci Hello World. Roz” hran´ı poskytuj´ıc´ı jedinou metodu String hello(String name) bude vypadat následovnˇe: 1 2 3

public interface HelloWorld extends java.rmi.Remote { public String hello(String name) throws java.rmi.RemoteException; } Zmiˇ nme snad jen dvˇe vˇeci - naˇse rozhran´ı mus´ı dˇedit z rozhran´ı Remote (z bal´ıˇcku java.rmi) a kaˇzd´ a metoda m˚ uˇze vyhazovat v´ yjimku RemoteException ze stejného bal´ıˇcku. Následuje implementace navrˇzeného rozhran´ı:

1 2

public class HelloWorldImpl extends java.rmi.server.UnicastRemoteObject implements HelloWorld {

3

public HelloWorldImpl() throws java.rmi.RemoteException { super(); }

4 5 6 7

public String hello(String name) throws java.rmi.RemoteException { return "Hello, " + name; }

8 9 10 11

} Vˇsimnˇeme si, ˇze implementace dˇed´ı ze tˇr´ıdy UnicastRemoteObject (tentokrát z bal´ıˇcku java.rmi.server) a je nutné, aby zde byl uveden konstruktor, kter´ y vyhazuje v´ yjimku RemoteException. M´ ame tedy vytvoˇrené rozhran´ı s jeho implementac´ı. Nyn´ı spust´ıme speciáln´ı RMI kompil´ ator (rmic) s parametrem tˇr´ıdy implementace, tedy: rmic HelloWorldImpl Tato volba vytvoˇr´ı v daném adresáˇri soubor HelloWorld_Stub.class a dle pouˇzité verze JDK pˇr´ıpadnˇe i soubor HelloWorld_Skel.class. Nyn´ı zb´ yvá vytvoˇrit samotnou tˇr´ıdu serveru a klienta. Server bude vypadat takto:

1

public class HelloWorldServer {

2 3 4 5 6 7 8 9 10 11 12

public HelloWorldServer() { try { HelloWorld helloWorld = new HelloWorldImpl(); java.rmi.Naming.rebind("rmi://localhost:1080/HelloWorldService", helloWorld); } catch (Exception e) { ... } }


24

public static void main(String args[]) { new HelloWorldServer(); }

13 14 15 16

} Jedná se pouze o vytvoˇren´ı implementace dané sluˇzby a jej´ı uveˇrejnˇen´ı v RMI registru (ˇrádky 6 a 7). Klient obsahuj´ıc´ı pouze nejnutnˇejˇs´ı pˇr´ıkazy ke zprovoznˇen´ı RMI komunikace bude podobnˇe jednoduch´ y:

1

public class HelloWorldClient {

2

public static void main(String[] args) { try { HelloWorld helloWorld = (HelloWorld) java.rmi.Naming.lookup( "rmi://localhost/HelloWorldService"); System.out.println(helloWorld.helloWorld("client")); } catch (Exception) { ... } }

3 4 5 6 7 8 9 10 11 12 13

} Na ˇrádku 5 a 6 se tedy pokus´ıme nalézt sluˇzbu, kterou server poskytuje a jej´ıˇz název mus´ıme znát (HelloWorldService). N´ aslednˇe pak provedeme volán´ı metody pˇres nalezené rozhran´ı. Oˇsetˇren´ı v´ yjimek by mˇelo b´ yt samozˇrejmˇe d˚ ukladnˇejˇs´ı neˇz jen zachytáván´ı obecné Exception. Mohou nastat r˚ uzné pˇr´ıpady, kdy hledán´ı rozhran´ı ˇci samotné volán´ı metody selˇze. V´ıce o zp˚ usobu pouˇzit´ı Java RMI se doˇctete v [66] a [33]. V pˇredchoz´ım textu jsme si podrobnˇe popsali princip a pouˇzit´ı Java RMI jako technologie pro distribuované aplikace na platformˇe Java. Pokud dnes vˇsak chceme vyvinout rozsáhlou (napˇr´ıklad webovou) aplikaci, programovac´ı jazyk Java nám nab´ız´ı mnohem dokonalejˇs´ı technologie, neˇz samotné Java RMI. Jednou takovou technologi´ı jsou tzv. Enterprise Java Beans (EJB), jejichˇz hlavn´ı souˇc´ ast je postavena na Java RMI a které jsou souˇcást´ı Java Enterprise Edition. Této technologii vˇenujeme celou podkapitolu 4.1.2.

Kapitola 3

Anal´ yza V u ´vodu (ˇc´ ast 1.1) jsme popsali c´ıle této diplomové práce. Mimo teoretické ˇcásti je c´ılem návrh a implementace serverového modulu informaˇcn´ıho systému pro správu nemovitost´ı. Jelikoˇz bude tento modul poskytovat veˇskerou funkˇcnost systému (klientsk´ y modul se bude starat pouze o prezentaˇcn´ı ˇc´ ast), je nutné v anal´ yze probrat stávaj´ıc´ı ˇreˇsen´ı a pokusit se z nich vyvodit poˇzadavky na IS takov´ ym zp˚ usobem, aby byl náˇs produkt konkurenceschopn´ y a pˇrináˇsel napˇr´ıklad nˇekteré unikátn´ı funkce, které jinde zákazn´ık nenajde. Na z´ avˇer v anal´ yze pop´ıˇseme typy uˇzivatel˚ u IS a scénáˇre pouˇzit´ı jednotliv´ ych funkc´ı, které bude aplikace poskytovat.

3.1

Informaˇ cn´ı syst´ em pro spr´ avu nemovitost´ı

Jak jsme zm´ınili v ˇc´ asti 2.3 na stranˇe 11, dneˇsn´ı v´ yznam vzdáleného volán´ı procedur je pˇredevˇs´ım v oblasti internetov´ ych aplikac´ı (resp. v oblasti Softwaru jako sluˇzby“), které ” pravdˇepodobnˇe ˇcasem u ´plnˇe nahrad´ı vˇsechny bˇeˇznˇe pouˇz´ıvané programy na poˇc´ıtaˇci. Pokud chceme tedy vyvinout produkt, kter´ y bude m´ıt velk´ y potenciál do budoucna, je velmi d˚ uleˇzité, aby bylo moˇzné pˇristupovat k funkc´ım systému odkudkoli (tak, jak to uv´ ad´ı zadán´ı), tedy jak napˇr´ıklad z webové, tak i z mobiln´ı aplikace. Ke vzniku tohoto projektu nav´ıc pˇrispˇelo zjiˇstˇen´ı, ˇze v oblasti aplikac´ı pro správu nemovitost´ı je pomˇernˇe mal´ a konkurence. Rozhodnˇe nelze ˇr´ıci, ˇze je na trhu dostateˇcn´ y v´ ybˇer z kvalitn´ıch ˇreˇsen´ı. Dnes, v dobˇe celosvˇetové ekonomické recese, sice mnoho odvˇetv´ı ztrác´ı trˇzn´ı potenci´ al a v´ ystavba bytov´ ych dom˚ u se moˇzná také zpomalila, ale poˇrád tyto domy pˇrib´ yvaj´ı velmi rychle a kaˇzd´ y je potˇreba nˇejak´ ym zp˚ usobem spravovat. C´ılem naˇseho IS je tedy poskytnout jednoduchou správu tˇechto nemovitost´ı s vyuˇzit´ım dneˇsn´ıch modern´ıch standard˚ u.

3.2

St´ avaj´ıc´ı ˇ reˇ sen´ı

Porovn´ an´ı st´ avaj´ıc´ıch ˇreˇsen´ı rozdˇel´ıme do dvou oblast´ı, a to na desktopové a webové aplikace.

25

´ KAPITOLA 3. ANALYZA

26

3.2.1

Desktopov´ e aplikace

I kdyˇz pˇredpokl´ ad´ ame, ˇze jako prvn´ı klientsk´ y modul bude vytvoˇren modul webov´ y (implementuje ho kolega Petr Horsk´ y), z hlediska funkˇcnosti celého systému (a tedy z hlediska funkˇcn´ıch poˇzadavk˚ u serverového modulu) mus´ıme porovnat jak webové, tak i desktopové aplikace. Právˇe ty desktopové oproti webov´ ym totiˇz disponuj´ı vˇetˇsinou v´ıce funkcemi. 3.2.1.1

Popis vybran´ ych aplikac´ı

Následuje popis jednotliv´ ych variant. Byly vybrány nejznámˇejˇs´ı programy z této oblasti softwaru. SSB2000, STARLIT s.r.o. Asi nejznámˇejˇs´ım a zároveˇ n nejrozˇs´ıˇrenˇejˇs´ım programem pro správu dom˚ u je aplikace SSB2000 od firmy STARLIT s.r.o. [76]. Tato firma se pohybuje na trhu se správou nemovitost´ı jiˇz patn´ act let a má zde v´ yrazné postaven´ı. Ukázka z programu je na obrázku 3.1.

Obr´ azek 3.1: Uk´ azka z programu SSB2000 od firmy STARLIT s.r.o.

´ ÍCÍ RE ˇ SEN ˇ Í 3.2. STAVAJ

27

Výhody: ∙ zaveden´ y program, ∙ moˇznost dokoupen´ı dalˇs´ıch navazuj´ıch modul˚ u (napˇr. podvojné u ´ˇcetnictv´ı), ∙ propojen´ı s dalˇs´ımi sluˇzbami (naˇc´ıtán´ı bankovn´ıch v´ ypis˚ u, odeˇct˚ u tepla atd.), ∙ v´ yborn´ y z´ akaznick´ y servis. Nevýhody: ∙ pomˇernˇe nepˇrehledné uˇzivatelské rozhran´ı (tato nev´ yhoda m˚ uˇze b´ yt odstranˇena kvalitn´ım zaˇskolen´ım, které firma nab´ız´ı), ∙ v z´ akladn´ı verzi pˇr´ıliˇs mnoho modul˚ u, malá flexibilita verz´ı. SOFTWARE 5P, Ing. Oldˇ rich Florian Program, jehoˇz majitel sv˚ uj produkt inzeruje v ˇcasopise urˇceném pro spr´ avce dom˚ u, je vytvoˇren v prostˇred´ı Microsoft Access 2007. To m˚ uˇze, ale také nemus´ı b´ yt v´ yhoda. Ukázka programu s nˇekolika otevˇren´ ymi okny je na obrázku 3.2. Dalˇs´ı informace naleznete v [73]. Výhody: ∙ pokud m´ a uˇzivatel na poˇc´ıtaˇci kanceláˇrsk´ y bal´ık MS Office, nepotˇrebuje program ˇz´ adnou instalaci, ∙ moˇznost exportu r˚ uzn´ ych tabulek do programu MS Excel. Nevýhody: ∙ v pˇr´ıpadˇe absence MS Office na poˇc´ıtaˇci nutnost dokoupen´ı MS Access, ∙ pomˇernˇe nepˇrehledné uˇzivatelské rozhran´ı, ∙ pouze primitivn´ı podpora s´ıt’ového provozu (sd´ılená databáze MS Access). Cactus Domus, C´ IGLER SOFTWARE, a.s. Firma provozuj´ıc´ı znám´ yu ´ˇcetn´ı software Money S3 vytvoˇrila také program pro správu nemovitost´ı. V´ıce na obrázku 3.3 a v [14]. Výhody: ∙ asi nejvˇetˇs´ı v´ yhodou je pˇr´ımé propojen´ı s u ´ˇcetn´ım systémem Money S3, coˇz dˇelá z této aplikace velmi podaˇren´ y produkt

28


Obrázek 3.2: Uk´ azka z programu SOFTWARE 5P od firmy Ing. Oldˇrich Florian.


Obr´ azek 3.3: Uk´ azka z programu Cactus Domus od firmy CÍGLER SOFTWARE, a.s.

29


30

∙ jednoduch´ a spr´ ava dom˚ u jakéhokoliv typu (majitel, druˇzstvo, spoleˇcenstv´ı vlastn´ık˚ u, firma) Nevýhody: ∙ u ´plná absence s´ıt’ové verze ∙ uˇzivatelské rozhran´ı p˚ usob´ı trochu neohrabanˇe, napˇr´ıklad u ´prava informac´ı o bytu je velmi nepˇrehledn´ a 3.2.1.2

Z´ avˇ er z porovn´ an´ı

Desktopov´ ych aplikac´ı pro spr´ avu nemovitost´ı existuje samozˇrejmˇe mnoho. Z vybran´ ych je pravdˇepodobnˇe nejlepˇs´ı SSB2000 od firmy STARLIT s.r.o. Obsahuje velké mnoˇzstv´ı dodateˇcn´ ych modul˚ u vˇcetnˇe modulu webového. Vˇsechny zde uvedené programy maj´ı vˇsak spoleˇcnou nev´ yhodu. I pˇresto, ˇze jsou modulárn´ı, nab´ızej´ı relativnˇe malou flexibilitu pˇri v´ ybˇeru tˇechto modul˚ u. V základn´ı verzi obsahuj´ı pˇr´ıliˇs mnoho poloˇzek, které pak znepˇrehledˇ nuj´ı uˇzivatelské rozhran´ı. Naˇse aplikace by mˇela tuto nev´ yhodu odstranit. Serverov´ y modul bude oddˇelenˇe poskytovat jednotlivé sluˇzby, které bude pl´ anovaná Rich Internet Application na klientské stranˇe vyuˇz´ıvat. Zákazn´ık si tak bude moci vybrat jen ty moduly, které opravdu potˇrebuje, a nebude muset platit za nˇeco, co nebude nikdy vyuˇz´ıvat.

3.2.2

Webov´ e aplikace

Na poli internetov´ ych aplikac´ı pro spr´ avu dom˚ u si zákazn´ık rozhodnˇe nem˚ uˇze pˇr´ıliˇs vyb´ırat. Existuj´ı bud’ nadstavby desktopov´ ych program˚ u (které ale ve vˇetˇsinˇe pˇr´ıpad˚ u nejsou plnohodnotné) nebo samostatné webové aplikace. 3.2.2.1

Popis vybran´ ych aplikac´ı

SSBnet, STARLIT s.r.o. Webov´ a nadstavba programu SSB2000 od firmy STARLIT s.r.o. [76] nab´ız´ı zobrazen´ı informac´ı z jednotliv´ ych modul˚ u na internetu, ukázka je na obrázku 3.4. Výhody: ∙ propojen´ı s jedn´ım z nejlepˇs´ıch desktopov´ ych program˚ u pro správu nemovitost´ı, ∙ pˇrehledné uˇzivatelské rozhran´ı. Nevýhody: ∙ pouze manu´ aln´ı export z programu SSB2000 do internetového modulu, ∙ vˇsechna data jsou na internetu pouze pro ˇcten´ı a nelze je upravovat.


Obr´ azek 3.4: Uk´ azka z aplikace SSBnet od firmy STARLIT s.r.o.

Obr´ azek 3.5: Uk´ azka z webové nadstavby aplikace WinDomy od firmy O.K. Soft.

31


32

Webov´ a nadstavba WinDomy, O.K. Soft Tato aplikace umoˇzn ˇuje automatické zobrazován´ı informac´ı z desktopového programu WinDomy. V´ıce na obrázku 3.5 a v [59]. Výhody: ∙ automatické zobrazov´ an´ı dat z aplikace WinDomy, ∙ moˇznost zobrazen´ı historick´ ych dat - napˇr. odstˇehovan´ ych uˇzivatel˚ u bytu. Nevýhody: ∙ nepˇrehledné zobrazen´ı dodateˇcn´ ych informac´ı (napˇr. pˇri zobrazen´ı nájemn´ıka se objev´ı menu pro pr´ aci s n´ım, ale zmiz´ı menu základn´ı) Building manager, Ikon s.r.o. Komplexn´ı webová aplikace Building manager umoˇzn ˇuje celkovou správu nemovitost´ı na internetu. Ukázka uˇzivatelského prostˇred´ı je na obrázku 3.6.

Obr´ azek 3.6: Uk´ azka z aplikace Building manager od firmy Ikon s.r.o. Výhody: ∙ aplikace umoˇzn ˇuje plnohodnotnou správu nemovitost´ı pouze na internetu, ∙ pˇrehledné menu. Nevýhody: ∙ pomalé naˇc´ıt´ an´ı, ∙ pro pohodlné zobrazen´ı je tˇreba velkého monitoru.

ˇ ´ 3.3. POZADAVKY NA SYSTEM

3.2.2.2

33

Z´ avˇ er z porovn´ an´ı

Z tohoto pˇrehledu je zˇrejmé, ˇze jediná aplikace Building manager m˚ uˇze b´ yt plnohodnotn´ ym ˇreˇsen´ım spr´ avy nemovitost´ı na internetu. Rozhodnˇe ale nem˚ uˇzeme ˇr´ıci, ˇze je tato aplikace pro uˇzivatele ide´ aln´ı. Moˇzn´ a se ˇcasem i dalˇs´ı desktopové aplikace, zm´ınˇené v´ yˇse, vydaj´ı cestou internetu a nebudou nab´ızet jen omezené internetové nadstavby pouze pro ˇcten´ı“. Dnes je ” vˇsak v této oblasti trhu rozhodnˇe voln´ y prostor.

3.3

Poˇ zadavky na syst´ em

Následuje seznam poˇzadavk˚ u na informaˇcn´ı systém. Nˇekteré vycházej´ı ze zadán´ı, jiné jsou odvozeny od probran´ ych st´ avaj´ıc´ıch ˇreˇsen´ı.

3.3.1

Funkˇ cn´ı poˇ zadavky

Z funkˇcn´ıch poˇzadavk˚ u probereme nejprve ty, které se t´ ykaj´ı samotné správy bytov´ ych dom˚ u, a poté pop´ıˇseme v samostatné ˇca´sti kl´ıˇcovou historickou funkci naˇseho IS. 3.3.1.1

Prostˇ redky pro spr´ avu bytov´ ych dom˚ u

Informaˇcn´ı systém popisovan´ y v tomto textu je velice rozsáhl´ y a souhrn vˇsech jeho funkc´ı pˇrevyˇsuje kapacitu této pr´ ace. N´ asleduj´ıc´ı funkce jsou tedy rozdˇeleny podle priorit od nejvyˇsˇs´ı (1) aˇz po nejniˇzˇs´ı (3). Implementace systému bude pak zamˇeˇrena na funkce prvn´ı priority. Následuj´ıc´ı funkˇcn´ı poˇzadavky jsou dále rozdˇeleny na ty, které se t´ ykaj´ı evidence vˇsech poloˇzek souvisej´ıc´ıch s domem, na poˇzadavky souvisej´ıc´ı s uˇzivateli aplikace a nakonec jsou zm´ınˇeny poˇzadavky (sp´ıˇse jako moˇznost rozˇs´ıˇren´ı), které souvisej´ı s r˚ uzn´ ymi komunikaˇcn´ımi nástroji, které m˚ uˇze aplikace nab´ıdnout. ∙ (1) R˚ uzné typy majitel˚ u domu - majitelem domu m˚ uˇze b´ yt druˇzstvo (z právn´ıho hlediska firma), spoleˇcenstv´ı vlastn´ık˚ u (coˇz je vlastnˇe soubor majitel˚ u s dan´ ym vlastnick´ ym pod´ılem) ˇci jeden nebo v´ıce samostatn´ ych majitel˚ u. ∙ Evidence r˚ uzn´ ych poloˇzek souvisej´ıc´ıch s domem: – (1) prostory v domˇe - byty, nebytové prostory (napˇr. kanceláˇre), chodby, gar´ aˇze, sklepy (kaˇzd´ y prostor m˚ uˇze nav´ıc obsahovat m´ıstnosti, které se budou také evidovat), – (2) zaˇr´ızen´ı a stavebn´ı souˇcásti - zaˇr´ızen´ım m˚ uˇze b´ yt napˇr´ıklad plynov´ y kotel v bytˇe, stavebn´ı souˇc´ ast´ı kupˇr´ıkladu eletrorozvody ˇci hromosvod, – osoby - jak´ akoli osoba“ v naˇsem systému m˚ uˇze b´ yt bud’ fyzickou nebo právnickou ” osobou (firmou), mezi evidované osoby patˇr´ı: * (1) majitel domu, * (1) majitel prostoru, * (2) obyvatel prostoru,


34

* * * *

(3) n´ ajemn´ık prostoru, (1) spr´ avce domu (napˇr´ıklad pˇredseda druˇzstva), m˚ uˇze m´ıt urˇcitou roli, (3) pracovn´ık domu (napˇr. ukl´ızeˇcka ˇci zahradn´ık), (3) d˚ uleˇzité kontakty (instalatér, elektrikáˇr apod. - narozd´ıl od pracovn´ıka domu, kter´ y pracuje pravidelnˇe, slouˇz´ı tento kontakt pouze pro jednorázové u ´ˇcely). Obecnˇe ke kaˇzdému prostoru ˇci domu m˚ uˇze b´ yt zaznamenáno v´ıce osob, je tedy moˇznost zaznamenat spolumajitele ˇci v´ıce obyvatel jednoho prostoru.

– (2) revize - ke kaˇzdému zaˇr´ızen´ı ˇci stavebn´ı souˇcásti mohou b´ yt zaznamenávány revize, – (2) smlouvy - smlouva se m˚ uˇze vztahovat k celému domu nebo k prostoru, m˚ uˇze b´ yt na dobu urˇcitou nebo neurˇcitou, – (3) platby - ke kaˇzdému prostoru mohou b´ yt evidovány platby (napˇr. platba za vodu, topen´ı ˇci n´ ajem), z tˇechto plateb m˚ uˇze b´ yt pak vypoˇc´ıtána celková suma, kterou mus´ı majitel/n´ ajemn´ık prostoru kaˇzd´ y mˇes´ıc platit, – (2) rekonstrukce - veˇskeré stavebn´ı souˇcásti domu (napˇr. fasáda) ˇci prostoru (napˇr. rozvod vody) mohou b´ yt rekonstruovány a tyto rekonstrukce mohou b´ yt zaznamen´ any; nen´ı vˇsak podm´ınkou m´ıt v evidenci danou stavebn´ı souˇcást, aby bylo moˇzné evidovat jej´ı rekonstrukci - m˚ uˇzeme evidovat rekonstrukci pouze obecnˇe a opravené souˇc´ asti zaznamenat jen do poznámky, – (3) dokumenty - r˚ uzné poloˇzky k sobˇe mohou m´ıt pˇriloˇzeny pˇr´ılohy (napˇr´ıklad u smlouvy, revize ˇci rekonstrukce) ∙ Uˇzivatelé aplikace - vˇse s prioritou (1): – pro pˇrihl´ aˇsen´ı do systému je nutné zadat e-mail a heslo, – kaˇzd´ y uˇzivatel m´ a v systému urˇcitou roli, ze které jsou odvozena jeho práva - tedy co se mu v systému zobraz´ı nebo jaké poloˇzky m˚ uˇze upravovat, – pro kaˇzdého uˇzivatele mus´ı existovat reálná evidovaná osoba (viz v´ yˇse), která je s uˇzivatelem spjata, – uˇzivatelské u ´ˇcty m˚ uˇze vytv´ aˇret pouze správce domu (zároveˇ n m˚ uˇze pˇriˇrazovat uˇzivatel˚ um urˇcité role a t´ım pádem i daná práva - jedin´ ym omezen´ım je to, ˇze správce nem˚ uˇze vytvoˇrit uˇzivatele s vyˇsˇs´ımi právy neˇz má on sám), – nového spr´ avce domu s jak´ ymikoli právy m˚ uˇze vytvoˇrit pouze uˇzivatel s nejvyˇsˇs´ımi právy v aplikaci, tedy napˇr´ıklad pracovn´ık spoleˇcnosti provozuj´ıc´ı informaˇcn´ı systém na internetu. ∙ Komunikaˇcn´ı n´ astroje - vˇse s prioritou (3): – nástˇenka - elektronick´ a obdoba nástˇenky na chodbˇe domu, – diskuzn´ı f´ orum - moˇznost diskuze napˇr. mezi sousedy jednoho domu, – funkce e-mailu - obyvatel nebo majitel prostoru si nebude moci zobrazit podrobné informace o ostatn´ıch sousedech, bude mu vˇsak umoˇznˇeno poslat e-mailovou zprávu jednomu nebo vˇsem soused˚ um bez znalosti konkrétn´ıch adres,

ˇ ´ 3.3. POZADAVKY NA SYSTEM

35

– anketa - pro u ´ˇcely hlasován´ı bude moci správce domu vytvoˇrit r˚ uzné ankety, které mohou pro v´ ypoˇcet váhy hlasu zohledˇ novat vlastnick´ y pod´ıl v domˇe (napˇr. u spoleˇcenstv´ı vlastn´ık˚ u) 3.3.1.2

Funkce ˇ casov´ ych ˇ rez˚ u

Nyn´ı pop´ıˇseme funkci ˇcasov´ ych ˇrez˚ u, tedy moˇznost zobrazit stav systému k libovolnému dni v minulosti, ale i v budoucnosti (nad rámec zadán´ı). Je totiˇz velmi v´ yhodné m´ıt moˇznost evidovat poloˇzky nejen v minulosti, ale i ty, které budou aktuáln´ı napˇr. aˇz za nˇekolik mˇes´ıc˚ u (jako pˇr´ıklad uved’me novou smlouvu na dobu urˇcitou ˇci nájemn´ıka bytu, kter´ y nastupuje aˇz za dva mˇes´ıce). Tato funkce je velmi d˚ uleˇzit´ a (má tedy prioritu 1) a pˇridá tomuto IS velkou v´ yhodu oproti konkurenˇcn´ım ˇreˇsen´ım. Nˇekteré programy sice um´ı napˇr´ıklad historicky zaznamenávat obyvatele bytu, ale tato a podobné funkce jsou pouze jednoduch´ ym rozˇs´ıˇren´ım jinak statického ukládán´ı dat. U kaˇzdého objektu je d˚ uleˇzité rozliˇsit informace, které se mohou v ˇcase mˇenit a které naopak ne nebo u kter´ ych nen´ı logické, aby byly tyto zmˇeny zaznamenávány. Vezmˇeme jako pˇr´ıklad evidenci bytu. Statické (nemˇenné) poloˇzky mohou b´ yt napˇr´ıklad: ∙ ˇc´ıslo bytu a ∙ podlaˇz´ı. Z dynamicky mˇen´ıc´ıch se informac´ı jmenujme kupˇr´ıkladu: ∙ majitele bytu, ∙ obyvatele bytu, ∙ poˇcet m´ıstnost´ı apod. V´ yˇse uvedené ˇc´ıslo bytu by se teoreticky v nˇejakém pˇr´ıpadˇe zmˇenit mohlo, ale je to pˇresnˇe ten pˇr´ıpad, kdy evidence této zmˇeny nen´ı ˇzádouc´ı, protoˇze se jedná sp´ıˇse o opravu p˚ uvodnˇe zadané hodnoty. ˇ Stejn´ y pˇr´ıpad je napˇr´ıklad u evidence osob. Reknˇ eme, ˇze budeme u majitele domu evidovat adresu trvalého bydliˇstˇe a kontaktn´ı adresu. Obˇe adresy se samozˇrejmˇe mohou zmˇenit, ale z pohledu naˇseho systému nen´ı potˇreba ukládat informaci o kontaktn´ı adrese majitele, která byla aktu´ aln´ı pˇred dvˇema lety. U informac´ı tohoto typu nás zaj´ımá vˇzdy jen souˇcasn´ a hodnota a zaznamen´ avat zmˇeny v historii by mˇelo naopak negativn´ı dopad na pˇrehlednost systému. Poˇzadavky t´ ykaj´ıc´ı se ˇcasov´ ych ˇrez˚ u na náˇs systém jsou tedy tyto: ∙ veˇskeré informace, které se mˇen´ı v ˇcase a u kter´ ych je tyto zmˇeny vhodné evidovat, jsou zaznamen´ av´ any historicky, ∙ jednoduch´ ym zp˚ usobem je moˇzno zobrazit informace k danému datu v minulosti i v budoucnosti,


36

∙ pˇri u ´pravˇe objekt˚ u (napˇr. domu) mus´ıme rozliˇsit tˇri alternativy: – nehistorick´ au ´prava - upravujeme statickou informaci objektu (napˇr. rok, kdy byl postaven d˚ um), v tomto pˇr´ıpadˇe se jedná pouze o opravu p˚ uvodnˇe (ˇspatnˇe) zadané hodnoty, – historick´ au ´prava - upravujeme dynamickou informaci (k nˇejakému datu) - v systému mus´ı z˚ ustat jak p˚ uvodn´ı informace, tak novˇe zadaná, – historick´ a oprava - ˇreknˇeme, ˇze jsme provedli u ´pravu dynamické informace, ale zjist´ıme, ˇze byla informace zadána ˇspatnˇe - potˇrebujeme tedy dynamickou informaci pouze opravit. M´ ame jeˇstˇe ale dvˇe moˇznosti: * p˚ uvodn´ı hodnotu smaˇzeme a vytvoˇr´ıme pro tento ˇcasov´ yu ´sek hodnotu novou (viz obr´ azek 3.7) - v ˇcasovém u ´seku mezi 5. 10. 1996 a 9. 5. 1998 jsme nahradili p˚ uvodnˇe zadan´ y typ m´ıstnosti ob´ yvac´ı pokoj“ za pokoj pro hosty“, ” ” * p˚ uvodn´ı hodnotu smaˇzeme, ale nevytvoˇr´ıme hodnotu novou, n´ ybrˇz jen urˇc´ıme, kter´ a sousedn´ı hodnota má vyplnit prázdné m´ısto (viz obrázek 3.8).

1)

Ložnice 2.3.1990

2)

Obývací pokoj 5.10.1996

9.5.1998

Pokoj pro hosty

Ložnice 2.3.1990

Dětský pokoj

5.10.1996

Dětský pokoj 9.5.1998

Obrázek 3.7: Historick´ a oprava dynamické informace - ˇreknˇeme, ˇze zpˇetnˇe ukládáme do systému typy jedné m´ıstnosti v bytˇe tak, jak byly postupnˇe rekonstruovány. Pˇri zadáván´ı ale udˇeláme chybu (1), kterou potˇrebujeme následnˇe opravit (2).

3.3.2

Nefunkˇ cn´ı poˇ zadavky

Nefunkˇcn´ı poˇzadavky definuj´ı napˇr´ıklad omezen´ı na v´ ykon systému, jeho design ˇci dalˇs´ı technické podrobnosti, které se pˇr´ımo net´ ykaj´ı funkc´ı, se kter´ ymi pˇrijde do styku uˇzivatel. Vzhledem k tomu, ˇze popisujeme serverov´ y modul tohoto informaˇcn´ıho systému, omez´ıme se pouze na nefunkˇcn´ı poˇzadavky, které mus´ı splˇ novat server, na kterém bude aplikace spuˇstˇena. Mezi nˇe patˇr´ı: ∙ provozov´ an´ı bez zv´ yˇsen´ ych n´ arok˚ u na v´ ykon serveru - vzhledem k typu aplikace se nepˇredpokl´ ad´ a, ˇze by i pˇri velkém mnoˇzstv´ı zákazn´ık˚ u (ˇrádovˇe stovky) byla aplikace pˇr´ıliˇs vyt´ıˇzena. Kdyby pro kaˇzdého zákazn´ıka systém evidoval pˇribliˇznˇe 200 uˇzivatel˚ u, celkov´ y poˇcet by jich byl 20 000. Vˇetˇsina z nich by se ale do systému pˇrihlaˇsovala pouze zˇr´ıdka (napˇr´ıklad jednou mˇes´ıˇcnˇe), coˇz pak odpov´ıdá pˇribliˇznˇe 120 uˇzivatel˚ u za hodinu

´ A ´ RE ˇ POUZIT ˇ Í 3.4. SCEN

1)

37

Ložnice 2.3.1990

2)

Obývací pokoj 5.10.1996

Ložnice 2.3.1990



Obrázek 3.8: Smaz´ an´ı historické zmˇeny - do systému jsme omylem zadali rekonstrukci m´ıstnosti, kter´ a vˇsak nebyla provedena, proto ji potˇrebujeme smazat (1) a následnˇe urˇcit, jak´ a sousedn´ı hodnota vypln´ı dan´ y ˇcasov´ yu ´sek (2). (pokud bereme v u ´vahu pouze 8 hodin kaˇzdého pracovn´ıho dne). Tento poˇcet uˇzivatel˚ u tedy rozhodnˇe nevyˇzaduje nˇejaké zvláˇstn´ı poˇzadavky na v´ ykon serveru, ∙ maxim´ aln´ı doba v´ ypadku systému bude jeden den, v pˇr´ıpadˇe delˇs´ıho v´ ypadku bude z´ akazn´ık˚ um nab´ızena finanˇcn´ı kompenzace, ∙ aktualizace na novou verzi bude provádˇena vˇzdy v noˇcn´ıch hodinách, ∙ produkt bude nab´ızen systémem software jako sluˇzba“ (viz ˇcást 2.3.2). ”

3.3.3

Poˇ zadavky klientsk´ eho modulu

Na závˇer je tˇreba jeˇstˇe definovat poˇzadavky, které jsou na serverov´ y modul kladeny od modulu klientského: ∙ komunikace prob´ıh´ a pomoc´ı vzdáleného volán´ı procedur (viz zadán´ı), ∙ rozhran´ı pro pˇripojen´ı klientského modulu mus´ı b´ yt univerzáln´ı - aby bylo moˇzno pˇripojit modul jakéhokoli typu (webovou aplikaci, tlust´ y klient ˇci mobiln´ı aplikaci).

3.4

Sc´ en´ aˇ re pouˇ zit´ı

Nyn´ı si pop´ıˇseme dle funkˇcn´ıch poˇzadavk˚ u priority (1) vˇsechny u ´kony, které mohou r˚ uzn´ı aktéˇri se systémem prov´ adˇet.

3.4.1

Popis akt´ er˚ u

Jak bylo zm´ınˇeno v ˇc´ asti 3.3.1.1, aplikace bude umoˇzn ˇovat pˇriˇradit uˇzivateli urˇcitou roli definuj´ıc´ı uˇzivatelsk´ a pr´ ava. Tyto role jsou vˇsak dynamické - správce domu m˚ uˇze vytvoˇrit jak´ ykoli poˇcet nov´ ych rol´ı s urˇcit´ ymi právy.


38

Abychom tedy mohli popsat pˇr´ıpady uˇzit´ı, mus´ıme definovat základn´ı uˇzivatelské role, od kter´ ych budou ty dynamické odvozené. Tyto základn´ı role budou obsahovat nejvyˇsˇs´ı moˇznou mnoˇzinu funkc´ı, které m˚ uˇze uˇzivatel pouˇz´ıvat, a dynamicky vytváˇrené role mohou pak tuto mnoˇzinu zmenˇsit, tedy odebrat uˇzivateli práva pro danou funkci. V následuj´ıc´ım popisu aktér˚ u vˇzdy nejprve uvedeme, které osoby jsou typicky s aktérem daného typu spjaty, protoˇze to nejlépe vystihuje mnoˇzinu povolen´ ych funkc´ı. Dˇediˇcnost aktér˚ u pak ukazuje obr´ azek 3.9. User Nejniˇzˇs´ı uˇzivatelsk´ a role se naz´ yvá User“. M˚ uˇze j´ım b´ yt obyvatel ˇci n´ ajemn´ık pros” toru nebo pracovn´ık domu. U d˚ uleˇzitých kontakt˚ u se nepˇredpokládá, ˇze by tyto osoby byly evidovány i jako uˇzivatelé aplikace. Superuser Typick´ y Superuser“ je majitel prostoru. Oproti aktérovi User“ má napˇr´ıklad ” ” pˇr´ıstup ke vˇsem informac´ım svého prostoru. Admin Jako Admin“ je v aplikaci oznaˇcen spr´ avce domu nebo jeho majitel. Má pˇr´ıstup ” ke vˇsem funkc´ım, které si dan´ y z´ akazn´ık, pouˇz´ıvaj´ıc´ı tento informaˇcn´ı systém, zaplat´ı. Superadmin Posledn´ım aktérem je Superadmin“. Tuto uˇzivatelskou roli m˚ uˇze m´ıt pouze ” pracovn´ık firmy provozuj´ıc´ı IS na internetu.

User

Superuser

Admin

Superadmin

Obr´ azek 3.9: Dˇediˇcnost aktér˚ u.

3.4.2

Podrobn´ y popis pˇ r´ıpad˚ u uˇ zit´ı

Nyn´ı si podrobnˇe pop´ıˇseme vˇsechny pˇr´ıpady uˇzit´ı uvedené na obrázku 3.10. Jsou rozdˇeleny do tˇr´ı základn´ıch modul˚ u (viz n´ıˇze). Z d˚ uvodu pˇrehlednosti jsou operace s r˚ uzn´ ymi objekty (napˇr. d˚ um, byt ˇci majitel) rozdˇeleny pouze do dvou skupin na: ∙ zobrazen´ı objektu (napˇr. zobrazit prostor“) a ” ∙ u ´pravu objektu (napˇr. odpov´ıdaj´ıc´ı upravit prostor“). ”


39

Modul Building Může také přidat nový dům

Omezení na dům, ve kterém bydlí

Zobrazit dům

Upravit dům

Zobrazit správce

Upravit správce

Zobrazit majitele

Upravit majitele

Superadmin Nemůže přidávat nový dům

Modul Space <> Zobrazit prostor

Upravit prostor

<> Zobrazit majitele

Upravit majitele

Zobrazit místnost

Upravit místnost <>

User

Modul Application Zobrazit uživatele <>

Upravit uživatele

Superuser

Zobrazit uživatelskou roli <>

Upravit uživatelskou roli

Obr´ azek 3.10: Pˇr´ıpady uˇzit´ı zohledˇ nuj´ıc´ı funkce priority (1).

Admin


40

Informační systém Přidat objekt <>

Upravit objekt

<>

Upravit stávající objekt

<>

Aktér s příslušnými právy

Smazat objekt Použije se jedna z možností

´ Obrázek 3.11: Pˇr´ıpady uˇzit´ı v pˇr´ıpadˇe u ´pravy“ objektu. Upravou se mysl´ı jak u ´prava jiˇz ” vytvoˇreného objektu, tak i pˇrid´ an´ı nového ˇci smazán´ı stávaj´ıc´ıho. ´ Uprava objektu vˇsak v tomto pˇr´ıpadˇe znamená jak u ´ pravu jiˇ z vytvoˇ ren´ eho objektu, tak i pˇ rid´ an´ı nového ˇci smaz´ an´ı st´ avaj´ıc´ıho. V´ıce na obrázku 3.11. V následuj´ıc´ım popisu pˇr´ıpad˚ u uˇzit´ı budeme tedy u ´pravou“ myslet tyto tˇri moˇznosti. ” Pokud se naopak jedn´ a pouze o zobrazen´ı objektu, je t´ım myˇsleno bud’ ∙ zobrazen´ı jednoho objektu nebo ∙ zobrazen´ı v´ıce objekt˚ u splˇ nuj´ıc´ıch dané podm´ınky (napˇr. vˇsechny m´ıstnosti v prostoru). Zobrazen´ı objekt˚ u je nav´ıc vˇzdy ovlivnˇeno konkrétn´ım datem, ke kterému chce uˇzivatel tyto objekty zobrazit (dle poˇzadavku pro funkci ˇcasov´ ych ˇrez˚ u - viz ˇcást 3.3.1.2). V pˇr´ıpadˇe, ˇze budeme tedy pˇr´ıpad uˇzit´ı popisovat napˇr. jako zobrazen´ı informac´ı o majitel´ıch“, mysl´ıme ” t´ım, ˇze se zobraz´ı majitelé k zadanému datu. C´ılem tohoto textu je n´ avrh a implementace serverov´ eho modulu aplikace, proto v následuj´ıc´ım popisu jednotliv´ ych funkc´ı nebudeme brát v u ´vahu, jak´ ym zp˚ usobem jsou dané funkce poskytnuty uˇzivateli (to obstarává klientsk´ y modul), ale sp´ıˇse, co pˇresnˇe nab´ızej´ı a jak je lze vyuˇz´ıt. 3.4.2.1

Pˇ r´ıpady uˇ zit´ı modulu Building

V tomto modulu se nach´ azej´ı funkce souvisej´ıc´ı s domem. Pˇredpokládáme, ˇze bude pˇrihláˇsen´ y uˇzivatel vˇzdy pracovat s jedn´ım zvolen´ ym domem, ke kterému se budou vztahovat vˇsechny operace (napˇr. zobrazen´ı spr´ avc˚ u).


41

1.1 Zobrazit d˚ um Zobraz´ı informace o domu, ve kterém uˇzivatel bydl´ı (pro aktéra User ), pˇr´ıpadnˇe kolekci dom˚ u s jejich informacemi pro aktéra Admin. 1.2 Upravit d˚ um Umoˇzn´ı upravit informace o domu. Jak jsme zm´ınili v´ yˇse, jako u ´pravu objektu bereme také jeho pˇrid´ an´ı ˇci smazán´ı. V tomto jediném pˇr´ıpadˇe mus´ıme vˇsak rozliˇsit pˇridán´ı a smaz´ an´ı domu, které m˚ uˇze provádˇet jenom Superadmin. 1.3 Zobrazit spr´ avce Zobraz´ı informace o správc´ıch domu. Pro aktéra User ˇci Superuser m˚ uˇze b´ yt zobrazen´ı omezené jen na nˇekteré role správc˚ u. 1.4 Upravit spr´ avce Umoˇzn´ı upravit správce domu. Omezen´ı je v tomto pˇr´ıpadˇe takové, ˇze správce domu nem˚ uˇze s´ am sebe jako správce smazat. 1.5 Zobrazit majitele Zobraz´ı informace o majitel´ıch domu s jejich vlastnick´ ymi pod´ıly. T´ım, ˇze je systém navrˇzen tak, ˇze jakákoli osoba m˚ uˇze b´ yt bud’ fyzickou nebo právnickou osobou, tak spolu s vlastnick´ ymi pod´ıly jednotliv´ ych majitel˚ u splˇ nuje tento návrh poˇzadavek na r˚ uzné typy majitel˚ u domu. 1.6 Upravit majitele Umoˇzn´ı upravit majitele domu. Po pˇridán´ı majitele m˚ uˇ ze b´ yt zkontrolov´ an souˇcet vˇsech vlastnick´ ych pod´ıl˚ u, kter´ y mus´ı dát hodnotu jedna. 3.4.2.2

Pˇ r´ıpady uˇ zit´ı modulu Space

Následuje podrobn´ y popis funkc´ı souvisej´ıc´ıch s prostorem a jeho m´ıstnostmi. 2.1 Zobrazit prostor Zobraz´ı informace o vˇsech prostorech, ke kter´ ym má dan´ y uˇzivatel nˇejak´ y vztah (bydl´ı v nˇem, vlastn´ı ho apod.). Pro správce ˇci majitele domu (aktér Admin) jsou to vˇsechny prostory v daném domˇe. 2.2 Upravit prostor Umoˇzn´ı upravit prostor v domˇe. Pˇri pˇridáván´ı prostoru je automaticky pˇrid´ ana i jeho prvn´ı m´ıstnost, v systému totiˇz nem˚ uˇze existovat prostor bez m´ıstnosti. 2.3 Zobrazit majitele Zobraz´ı vˇsechny majitele daného prostoru s jejich vlastnick´ ymi pod´ıly. 2.4 Upravit majitele Umoˇzn´ı upravit majitele prostoru. Po pˇridán´ı nového majitele m˚ uˇ ze b´ yt zkontrolov´ an souˇcet vˇsech vlastnick´ ych pod´ıl˚ u, kter´ y mus´ı dát hodnotu jedna. 2.5 Zobrazit m´ıstnost

Zobraz´ı vˇsechny m´ıstnosti pˇr´ısluˇsej´ıc´ı k danému prostoru.

2.6 Upravit m´ıstnost Umoˇzn´ı upravit m´ıstnost. Pˇri mazán´ı m´ıstnosti je kontrolov´ ano, jestli nen´ı dan´ a m´ıstnost jedin´ a, kterou prostor obsahuje, v tom pˇr´ıpadˇe nen´ı smazán´ı dovoleno (viz pˇr´ıpad uˇzit´ı ˇc´ıslo 2.2).


42

3.4.2.3

Pˇ r´ıpady uˇ zit´ı modulu Application

V modulu Application se nach´ azej´ı funkce pro správu uˇzivatelsk´ ych u ´ˇct˚ u v aplikaci. 3.1 Zobrazit uˇ zivatele Zobraz´ı informace o pˇrihláˇseném uˇzivateli, pˇr´ıpadnˇe (pokud na to má dan´ y uˇzivatel pr´ ava) zobraz´ı vˇsechny uˇzivatele v aplikaci. Zobrazen´ı pak m˚ uˇze b´ yt omezeno na uˇzivatele zvoleného domu ˇci na uˇzivatele jednoho zákazn´ıka. 3.2 Upravit uˇ zivatele Pˇrihl´ aˇsen´ y uˇzivatel si touto funkc´ı m˚ uˇze zmˇenit napˇr´ıklad pˇr´ıstupové heslo ˇci e-mail. Spr´ avce domu m˚ uˇze upravovat jakéhokoli uˇzivatele pˇr´ısluˇsej´ıc´ıho k dom˚ um, které spravuje. 3.3 Zobrazit uˇ zivatelskou roli Zobraz´ı vˇsechny dostupné uˇzivatelské role pro daného zákazn´ıka. 3.4 Upravit uˇ zivatelskou roli Umoˇzn ˇuje upravit uˇzivatelskou roli. Pˇri pˇridáván´ı nové role nebo pˇri u ´pravˇe pr´ av st´ avaj´ıc´ı role je zde d˚ uleˇzité omezen´ı: nem˚ uˇze b´ yt pˇridána/upravena role s vyˇsˇs´ımi pr´ avy, neˇz m´ a pr´ avˇe pˇrihl´ aˇsen´ y uˇzivatel. 3.4.2.4

Pˇ r´ıpady uˇ zit´ı v r´ amci pr´ ace s dynamick´ ymi daty

Obrázek 3.10 ukazuje vˇsechny pˇr´ıpady uˇzit´ı, které mohou nastat pˇri základn´ım pouˇzit´ı aplikace. Jelikoˇz je vˇsak tento IS navrˇzen tak, aby umoˇzn ˇoval historicky zaznamenávat vˇsechna data, u kter´ ych je to potˇreba, mus´ıme jeˇstˇe rozˇs´ıˇrit funkce o pˇr´ıpady uˇzit´ı t´ ykaj´ıc´ı se práce s dynamick´ ymi (historick´ ymi) daty. Tyto pˇr´ıpady uˇzit´ı uvád´ı obrázek 3.12. Nejedná se vˇsak o pˇr´ıpady uˇzit´ı, které se vztahuj´ı ke konkrétn´ımu aktérovi, bereme naopak v u ´vahu, ˇze vˇsechny uvedené operace m˚ uˇze s objektem provádˇet aktér, kter´ y má (v pˇredchoz´ım schématu) pr´ ava k jeho u ´pravˇe. 4.1 Zobrazit historick´ e zmˇ eny Uˇzivatel z´ıská kolekci vˇsech zmˇen dynamick´ ych dat, která jsou k danému objektu zaznamen´ ana. 4.2 Opravit historickou zmˇ enu Umoˇzn ˇuje opravit hodnotu dynamické informace, která je jiˇz historicky zaznamen´ ana. Na obr´ azku 3.7 na stranˇe 36 je tato oprava znázornˇena. Mus´ıme si totiˇz uvˇedomit, ˇze pokud dynamickou informaci uprav´ıme, je zaznamenána jak jej´ı stará hodnota, tak i hodnota novˇe zadan´ a. Pokud bychom v této chv´ıli opravili“ danou informaci ” na p˚ uvodn´ı hodnotu klasick´ ym zp˚ usobem, byly by v systému zaznamenány ve v´ ysledku hodnoty tˇri (p˚ uvodn´ı, zmˇenˇen´ a a opˇet zmˇenˇená, avˇsak s p˚ uvodn´ı hodnotou). 4.3 Smazat historickou zmˇ enu Nˇekdy nepotˇrebujeme historicky zaznamenanou zmˇenu opravit (jako v pˇredchoz´ım pˇr´ıpadˇe), ale vymazat - k tomu slouˇz´ı tato funkce. Uˇzivatel m˚ uˇze dále urˇcit, jak´ ym zp˚ usobem se maj´ı ostatn´ı zmˇeny slouˇcit (viz obrázek 3.8 na stranˇe 37).


43

Informační systém

Opravit historickou změnu <>

Zobrazit historické změny

Aktér s příslušnými právy

<> Smazat historickou změnu

Obr´ azek 3.12: Pˇr´ıpady uˇzit´ı pro práci s dynamick´ ymi daty.

44


Kapitola 4

V´ ybˇ er a popis technologi´ı V pˇredch´ azej´ıc´ı kapitole jsme provedli anal´ yzu, ze které vycházej´ı funkce aplikace, jeˇz je tˇreba navrhnout. N´ avrh vˇsak jiˇz zohledˇ nuje technologie, ve kter´ ych bude systém poté implementován, proto nyn´ı tyto technologie vybereme na základˇe zadán´ı a dostupn´ ych moˇznost´ı.

4.1

Vzd´ alen´ e vol´ an´ı procedur (RPC)

Zadán´ı n´ am urˇcuje pouˇzit´ı platformy Java a vzdáleného volán´ı procedur. Jak jste se doˇcetli v ˇcásti 2.5, vzd´ alené vol´ an´ı procedur na platformˇe Java je implementováno pomoc´ı Java RMI. Ze zad´ an´ı tedy plyne nutnost pouˇzit´ı této technologie.

4.1.1

Popis a porovn´ an´ı technologi´ı

Co vˇsak m˚ uˇzeme vybrat (aby tento v´ ybˇer stále odpov´ıdal zadán´ı), je technologie, která pˇr´ıpadnˇe zastˇreˇs´ı pouˇzit´ı Java RMI. Následuj´ıc´ı dva odstavce popisuj´ı nejprve pouˇzit´ı samotného RMI a poté vyuˇzit´ı Enterprise Java Beans v rámci Java Enterprise Edition, coˇz je technologie, jej´ıˇz hlavn´ı ˇc´ ast (session beans) je postavená na RMI. Samostatn´ e RMI Vlastnosti a pouˇzit´ı samostatné technologie Java RMI jsme popsali v kapitole Vzd´ alené vol´ an´ı procedur“, konkrétnˇe v ˇcásti 2.5. ” V´ yhody tohoto pouˇzit´ı RMI jsou následuj´ıc´ı: ∙ nepotˇrebujeme ˇz´ adné dalˇs´ı knihovny a technologie, pouˇzijeme standardn´ı funkˇcnost jazyka Java, ∙ vytvoˇren´ı rozhran´ı pro klientsk´ y modul je velmi jednoduché, jakoˇzto i jeho implementace, ∙ aplikace m˚ uˇze b´ yt spuˇstˇena na jakémkoli serveru s podporou platformy Java. Samostatné RMI m´ a vˇsak tu nev´ yhodu, ˇze z hlediska zabezpeˇcen´ı nab´ız´ı pouze standardn´ı prostˇredky, které jsou souˇc´ ast´ı platformy Java 2. Aplikace má nastavena r˚ uzná povolen´ı k urˇcit´ ym ˇcinnostem, tato povolen´ı pak kontroluje Security Manager [33].

45

´ ER ˇ A POPIS TECHNOLOGIÍ KAPITOLA 4. VYB

46

Pokud bychom vˇsak chtˇeli pouˇz´ıt nˇejaká povolen´ı na u ´rovni uˇzivatel˚ u, museli bychom vytvoˇrit vlastn´ı ˇreˇsen´ı ˇci pouˇz´ıt nˇejaké dodateˇcné knihovny.

Enterprise Java Beans v r´ amci Java Enterprise Edition Velmi odliˇsnou variantou pro splnˇen´ı zad´ an´ı je pouˇzit´ı platformy Java Enterprise Edition (Java EE), coˇz je soubor technologi´ı pro v´ yvoj rozs´ ahl´ ych enterprise aplikac´ı1 . Právˇe technologie Enterprise Java Beans (EJB), jej´ıˇz hlavn´ı ˇc´ ast - tzv. session beans“ - je jádrem aplikaˇcn´ı logiky, vyuˇz´ıvá pro ko” munikaci klient-server pr´ avˇe RMI [62]. Základn´ı pouˇzit´ı session beans je velmi podobné pouˇzit´ı samotného RMI. Opˇet mus´ıme vytvoˇrit rozhran´ı, které klient z´ısk´ a a které definuje podporované funkce. Toto rozhran´ı pak na serveru implementujeme. Mezi v´ yhody této technologie patˇr´ı zejména moˇznost pouˇ zit´ı EJB v r´ amci cel´ e platformy Java EE, kter´ a nab´ız´ı vˇsechny prostˇredky pro v´ yvoj enterprise aplikace, kterou náˇs informaˇcn´ı systém je. Mus´ıme vˇsak jeˇstˇe podotknout, ˇze bychom mohli pouˇz´ıt samostatné RMI z pˇredchoz´ı alternativy i v platformˇe Java EE. Ztratili bychom t´ım ale vˇsechny v´ yhody, které nab´ız´ı technologie EJB, jej´ıˇz ˇc´ ast je sice postavená na RMI, ale nab´ız´ı i mnoho dalˇs´ıch nástroj˚ u. Uved’me vˇsak také v´ yznamnou nev´ yhodu celé Java EE technologie: pokud nemá programátor s touto platformou zkuˇsenosti, nen´ı pˇr´ıliˇs jednoduché ji nastudovat tak, aby v n´ı mohl vytváˇret kvalitn´ı aplikace. To vyˇzaduje pomˇernˇe hodnˇe zkuˇsenost´ı.

4.1.2

Vybran´ a technologie: Java Enterprise Edition

Nejen kv˚ uli zkuˇsenostem v oblasti platformy Java EE jsme se rozhodli, ˇze pouˇzijeme tuto technologii. Jmenujme dalˇs´ı hlediska, proˇc byla technologie vybrána oproti samotnému RMI: ∙ vyuˇzijeme mnoho prostˇredk˚ u, které Java EE nab´ız´ı, jako napˇr´ıklad: – podporu pro autentizaci klienta, – zabezpeˇcené vol´ an´ı metod EJB (r˚ uzné metody m˚ uˇzeme povolit jen nˇekter´ ym uˇzivatelsk´ ym rol´ım), – pˇr´ıpadnou integraci s Java Persistence API pro komunikaci s databázovou vrstvou, ∙ v oblasti samotného RMI nab´ız´ı Java EE dostateˇcnou m´ıru abstrakce, abychom se nemuseli zab´ yvat nˇekter´ ymi aspekty RMI komunikace, ∙ technologie EJB pak dokonce umoˇzn ˇuje pouˇz´ıt stejné EJB tˇr´ıdy jak pro implementaci RMI rozhran´ı, tak pro implementaci webové sluˇzby. Tato kombinace nab´ız´ı velk´ y potenciál pro rozˇsiˇritelnost aplikace i jako webové sluˇzby. 1 Slovem enterprise je v angliˇctinˇe z ekonomického hlediska myˇslena firma ˇci spoleˇcnost, z hlediska poˇc´ıtaˇcového jsou pak enterprise aplikacemi myˇsleny ty, které jsou pouˇz´ıv´ any ve velk´ ych firm´ ach a operuj´ı s rozs´ ahl´ ymi daty.

´ ´ VOLAN ´ Í PROCEDUR (RPC) 4.1. VZDALEN E

4.1.2.1

47

Popis platformy Java EE

Technologie Java je dnes jednak programovac´ım jazykem, ale také platformou - tedy prostˇred´ım, ve kterém Java aplikace funguj´ı a které umoˇzn ˇuje programátorovi pouˇzit´ı nejr˚ uznˇejˇs´ıch prostˇredk˚ u pˇri v´ yvoji softwaru. Podle toho, jaké aplikace chceme vytváˇret, máme na v´ ybˇer dokonce z nˇekolika Java platforem: ∙ Java Standard Edition - j´ adro programovac´ıho jazyka, obsahuje základn´ı funkce, virtu´ aln´ı stroj a dalˇs´ı nezbytné technologie pro chod Java aplikac´ı, ∙ Java Micro Edition - pokud chceme vyv´ıjet Java aplikace pro mobiln´ı zaˇr´ızen´ı, pouˇzijeme tuto platformu, kter´ a je uzp˚ usobená pro bˇeh na ménˇe v´ ykonn´ ych systémech, ∙ JavaFX - platforma pro tvorbu tzv. Rich Internet Applications2 , ∙ Java Enterprise Edition (viz n´ıˇze). Java Enterprise Edition (Java EE) rozˇsiˇruje moˇznosti Java Standard Edition a nab´ız´ı prostˇredky pro v´ yvoj rozs´ ahl´ ych serverov´ ych aplikac´ı (ˇcasto se setkáváme s oznaˇcen´ım en” terprise aplikace“). Tyto aplikace se skládaj´ı vˇzdy z nˇekolika vrstev [92]: ∙ Klientsk´ a vrstva - klientem se v tomto pˇr´ıpadˇe rozum´ı napˇr´ıklad desktopová aplikace ˇci webov´ y prohl´ıˇzeˇc nebo dokonce jin´ y server. Tyto klientské poˇc´ıtaˇce pos´ılaj´ı poˇzadavky na server, kde je nasazena aplikace, a ten jim vrac´ı odpovˇedi. ∙ Webov´ a vrstva se star´ a o komunikaci klientské a business vrstvy (viz dále). Obsahuje technologie jako napˇr. servlety3 , JSP stránky4 ˇci JavaBean komponenty5 . ∙ Business vrstva - obsahuje aplikaˇcn´ı logiku naˇs´ı aplikace a pˇr´ıpadnˇe také doménov´ y model. Souˇc´ ast´ı této vrstvy jsou právˇe Enterprise Java Beans (zajiˇst’uj´ıc´ı aplikaˇcn´ı logiku), JPA entity6 a dalˇs´ı. ∙ Enterprise Information Systems - posledn´ı vrstvou v architektuˇre Java Enterprise aplikace je tzv. EIS vrstva, která typicky obsahuje databázov´ y server a dalˇs´ı technologie umoˇzn ˇuj´ıc´ı propojen´ı s jin´ ymi systémy. Tato vrstevnat´ a architektura je znázornˇena na obrázku 4.1. Zmiˇ nme jeˇstˇe, ˇze aplikace nemus´ı obsahovat webovou vrstvu, protoˇze je moˇzné vytvoˇrit klientskou aplikaci (napˇr´ıklad desktopovou), kter´ a bude komunikovat pˇr´ımo s EJB kontejnerem. 2 Rich Internet Applications jsou modern´ı internetové aplikace, které nab´ızej´ı stejné funkce jako aplikace desktopové, a tak je mohou plnohodnotnˇe nahradit [13]. V´ıce se o tˇechto aplikac´ıch dozv´ıte v ˇca ´sti 2.3.1. 3 Servlet je Java tˇr´ıda, kter´ a slouˇz´ı k obslouˇzen´ı HTTP poˇzadavku klientského poˇc´ıtaˇce a generov´ an´ı odpovˇedi [35]. 4 JSP str´ anky nab´ızej´ı zp˚ usob, kdy m˚ uˇzeme smˇeˇsovat statické HTML str´ anky s dynamicky generovan´ ym obsahem, kter´ y dod´ avaj´ı servlety [35]. 5 JavaBean komponenta je bˇeˇzn´ a Java tˇr´ıda s nˇekolika speci´ aln´ımi pravidly: mus´ı obsahovat pr´ azdn´ y konstruktor, nesm´ı m´ıt ˇza ´dné veˇrejné instanˇcn´ı promˇenné a k hodnot´ am, které mohou b´ yt upraveny, se mus´ı pˇristupovat pomoc´ı metod getXxx resp. setXxx. Tato tˇr´ıda pak m˚ uˇze b´ yt pouˇzita napˇr´ıklad spolu s HTML formul´ aˇrem a JSP str´ anka automaticky zajist´ı jej´ı sp´ arov´ an´ı s hodnotami formul´ aˇre [35]. 6 JPA entity jsou speci´ aln´ı Java tˇr´ıdy, které pˇredstavuj´ı persistentn´ı data aplikace. Typicky tak jedna JPA entita pˇredstavuje jednu tabulku v datab´ azi, nemus´ı tomu tak vˇsak b´ yt vˇzdy. JPA entity pouˇz´ıvaj´ı specia ´ln´ı anotace k urˇcen´ı prim´ arn´ıho kl´ıˇce, typu atribut˚ u a dalˇs´ıch informac´ı, které koresponduj´ı s datab´ azovou tabulkou [46].


48

Klientská vrstva

Prohlížeč

Desktopová Java aplikace

Webová vrstva

Business vrstva

Webový server

EJB kontejner

JSP

EJB

Enterprise Information System

JSP EJB Servlet

Nějaká další klientská Java aplikace

EJB Servlet

Obr´ azek 4.1: Vrstevnat´ a architektura Java Enterprise Edition. 4.1.2.2

Enterprise Java Beans

Enterprise Java Beans jsou j´ adrem Java EE aplikace. V následuj´ıc´ım textu budeme popisovat v´ yhradnˇe EJB verze 3.0. Od pˇredchoz´ı verze totiˇz doˇslo v této technologii k v´ yznamn´ ym zmˇenám a vylepˇsen´ım a neexistuje dnes jedin´ y d˚ uvod pouˇz´ıvat starou verzi. Komponenty v EJB kontejneru se dˇel´ı na: ∙ Session beans - zajiˇst’uj´ı hlavn´ı ˇc´ ast aplikaˇcn´ı logiky - v naˇsem pˇr´ıpadˇe zejména operace s databáz´ı, ∙ Message-driven beans - slouˇz´ı ke komunikaci mezi Java EE komponentami pomoc´ı zpráv. Session beans jsou komponenty, jejichˇz metody jsou volány klientem, kter´ y poˇzaduje po serveru urˇcitou funkci. Jedn´ a se pr´ avˇe o ty komponenty, které v pˇr´ıpadˇe, ˇze se klient nenacház´ı na stejném poˇc´ıtaˇci jako server, komunikuj´ı pomoc´ı RMI. Dˇel´ı se dále na dva typy: stateful a stateless session beans [62]. ∙ Typ stateful oznaˇcuje takovou session bean, která uchovává sv˚ uj stav v pr˚ ubˇehu klientského pˇripojen´ı (v pˇr´ıpadˇe webového klienta to je nejdéle doba, jakou existuje session daného webového prohl´ıˇzeˇce). Pˇr´ıkladem takové stateful session bean m˚ uˇze b´ yt objekt uchovávaj´ıc´ı poloˇzky n´ akupn´ıho koˇs´ıku pˇri nákupu v internetovém obchodˇe.

´ ´ VOLAN ´ Í PROCEDUR (RPC) 4.1. VZDALEN E

49

∙ Naopak typ stateless neuchovává ˇzádná data a je vhodné ho pouˇz´ıt pro jednorázové funkce (napˇr´ıklad uloˇzen´ı záznamu do databáze). Session beans tohoto typu mohou b´ yt uveˇrejnˇeny jako webové sluˇzby. Zvl´ aˇstn´ı komponentou jsou tzv. entity, které slouˇz´ı k objektovˇe-relaˇcn´ımu mapován´ı, a na rozd´ıl od pˇredchoz´ıch nejsou spravovány pˇr´ımo EJB kontejnerem (i kdyˇz do nˇej patˇr´ı), ale speciáln´ım n´ astrojem zvan´ ym Entity Manager.

4.1.2.3

Zabezpeˇ cen´ı Java EE

Platforma Java EE nab´ız´ı prostˇredky pro celkové zabezpeˇcen´ı aplikace. Nejd˚ uleˇzitˇejˇs´ım prvkem zabezpeˇcen´ı je autentizace klienta. V definici enterprise aplikace m˚ uˇzeme urˇcit, které prvky aplikace jsou zabezpeˇcené (pro webovou aplikaci to mohou b´ yt kupˇr´ıkladu vˇsechny kromˇe pˇrihlaˇsovac´ı str´ anky) a postup komunikace klienta se serverem pak vypadá n´ asledovnˇe: 1. klient se dot´ aˇze na zobrazen´ı zabezpeˇceného prvku, 2. server zjist´ı, zda-li je klient autentizován, pokud ano, pokraˇcuje na bod 5, pokud ne, pokraˇcuje d´ ale: 3. vyˇz´ ad´ a si od klienta zad´ an´ı pˇrihlaˇsovac´ıch u ´daj˚ u (u webové aplikace klientovi napˇr´ıklad zobraz´ı pˇrihlaˇsovac´ı str´ anku), 4. pokud server ovˇeˇr´ı totoˇznost klienta, pokraˇcuje dále, jinak klientovi nahlás´ı zad´ an´ı ˇspatn´ ych pˇrihlaˇsovac´ıch u ´daj˚ u, 5. server poskytne klientovi dotazovan´ y prostˇredek (napˇr´ıklad webovou stránku). Pokud poté prob´ıh´ a komunikace pomoc´ı RMI (na u ´rovni EJB kontejneru), je tato komunikace v pˇr´ıpadˇe u ´spˇeˇsné autentizace klienta zabezpeˇcena. Kaˇzd´ y klient, kter´ y se chce do zabezpeˇcené aplikace pˇripojit, mus´ı m´ıt tedy pˇriˇrazeno: ∙ uˇzivatelské jméno, ∙ heslo a ∙ uˇzivatelskou roli. Vˇsechny tyto poloˇzky musej´ı b´ yt definovány na serveru, tedy napˇr´ıklad v databázi. Velmi d˚ uleˇzit´ a je posledn´ı zm´ınˇen´ a poloˇzka - uˇzivatelská role. Pomoc´ı n´ı totiˇz m˚ uˇzeme omezit pˇr´ıstup k metod´ am session beans tˇr´ıd. EJB kontejner pak pˇri kaˇzdém volán´ı session bean metody kontroluje, zda-li m´ a pˇrihláˇsen´ y uˇzivatel k této akci práva [46].


50

4.2

Funkce ˇ casov´ ych ˇ rez˚ u

To, co definuj´ı ˇcasové ˇrezy, jsou vlastnˇe funkce temporárn´ı databáze. Temporárn´ı znamená obecnˇe pˇrechodn´ y“ ˇci doˇcasn´ y“, temporárn´ı databáze jsou pak ty, kde maj´ı poloˇzky své ” ” ˇcasové raz´ıtko a m˚ uˇzeme se pt´ at, jakou hodnotu mˇela daná poloˇzka v dan´ y ˇcas. V anal´ yze jsme popsali, jaké jsou poˇzadavky na tuto funkˇcnost z hlediska naˇseho informaˇcn´ıho systému. Nyn´ı probereme moˇznosti, kter´ ymi se dá této funkˇcnosti dosáhnout.

4.2.1

Moˇ znosti n´ avrhu tempor´ arn´ı funkˇ cnosti

Abychom mohli k datab´ azi pˇristupovat jako k databázi temporárn´ı, máme dvˇe hlavn´ı moˇznosti, které m˚ uˇzeme pouˇz´ıt: ∙ speciáln´ı datab´ aze s tempor´ arn´ım SQL rozˇs´ıˇren´ım, ∙ vlastn´ı zp˚ usob n´ avrhu datab´ aze, kter´ y umoˇzn´ı pouˇz´ıvat temporárn´ı funkce ve standardn´ım SQL. Datab´ aze s tempor´ arn´ım SQL rozˇ s´ıˇ ren´ım Teoretické snahy o temporárn´ı rozˇs´ıˇren´ı SQL existuj´ı jiˇz velmi dlouho [70], avˇsak v oblasti implementac´ı tohoto rozˇs´ıˇren´ı mus´ıme konstatovat, ˇze nen´ı vˇzdy jednoduché zavést nˇejak´ y teoretick´ y koncept do praktického vyuˇzit´ı, protoˇze datab´ az´ı, které podporuj´ı dotazovac´ı jazyk TSQL, je velmi málo. Jedn´ım z d˚ uvod˚ u m˚ uˇze b´ yt to, ˇze aktu´ aln´ı specifikace jazyka TSQL2 ˇc´ıtá kolem 700 stránek [47]. Momentálnˇe existuj´ı dva odliˇsné pˇr´ıstupy, jak lze dosáhnout toho, aby daná databáze implementovala TSQL rozˇs´ıˇren´ı [47][84]: ∙ integrované ˇreˇsen´ı - v této variantˇe je Database Management System (DBMS) jiˇz od základ˚ u upraven tak, aby podporoval práci s ˇcasov´ ymi daty, ∙ vrstevnaté ˇreˇsen´ı naopak stav´ı na základu tradiˇcn´ıho DBMS a pˇridává speciáln´ı temporárn´ı vrstvu, kter´ a se star´ a o zpracován´ı TSQL dotaz˚ u, jeˇz jsou konvertovány na standardn´ı SQL dotazy. Ze souˇcasn´ ych technologi´ı, které podporuj´ı temporárn´ı rozˇs´ıˇren´ı TSQL, m˚ uˇzeme jmenovat: ∙ Oracle Workspace Manager [61] je modul databáze Oracle 11g, kter´ y umoˇzn ˇuje práci s aktuáln´ımi, historick´ ymi i budouc´ımi“ daty. V aktuáln´ı verzi podporuje TSQL verze 2. ” Licence Oracle datab´ aze je vˇsak velmi drahá (Enterprise verze, jej´ıˇz souˇcást´ı je modul Workspace Manager, stoj´ı aktu´ alnˇe pˇribliˇznˇe 20 000 Kˇc), proto nen´ı pro naˇse pouˇzit´ı toto ˇreˇsen´ı vhodné. ∙ TimeDB [77], jej´ıˇz implementace je popsána v dizertaci Andrease Steinera [78], je funkˇcn´ı tempor´ arn´ı datab´ aze, avˇsak posledn´ı jej´ı verze je z roku 2005 a jedná se sp´ıˇse o projekt z akademického prostˇred´ı neˇz o databázi otestovanou v reálném nasazen´ı.

ˇ ´ ˇ U ˚ 4.2. FUNKCE CASOV YCH REZ

51

∙ Bal´ıˇcek temporal [65] v r´ amci databáze PostgreSQL [64] nab´ız´ı rozˇs´ıˇren´ı funkc´ı datab´ aze o pr´ aci s ˇcasov´ ymi daty. Projekt je vˇsak stále ve v´ yvojovém stádiu. ˇ sen´ı datab´ Reˇ aze s tempor´ arn´ım rozˇs´ıˇren´ım má jasnou v´ yhodu - nen´ı potˇreba vym´ yˇslet nov´ y zp˚ usob dotazov´ an´ı, ale pouˇzijeme jiˇz hotové rozˇs´ıˇren´ı SQL. Jak je vˇsak patrné z v´ yˇse uvedeného pˇrehledu, nev´ yhoda je také zˇrejmá - mus´ıme pro chod naˇseho systému pouˇz´ıt databázi, kter´ a toto rozˇs´ıˇren´ı podporuje, a nem˚ uˇzeme ˇr´ıci, ˇze bychom si mohli vybrat z mnoha (kvalitn´ıch) moˇznost´ı. Jedin´ ym reálnˇe pouˇziteln´ ym ˇreˇsen´ım je databáze od firmy Oracle, která je vˇsak moment´ alnˇe nad naˇse finanˇcn´ı moˇznosti. Vˇsechny v´ yˇse uvedené implementace maj´ı jeˇstˇe jednu spoleˇcnou nev´ yhodu: pro pr´ aci s datab´ az´ı bychom nemohli pouˇz´ıt objektovˇe-relaˇcn´ı mapován´ı (popsané n´ıˇze, v ˇcásti 4.3), coˇz je velmi omezuj´ıc´ı. Vlastn´ı sch´ ema s poloˇ zkami fromDate a toDate Pokud bychom nepouˇzili datab´ azi s tempor´ arn´ım rozˇs´ıˇren´ım, mus´ıme vytvoˇrit vlastn´ı ˇreˇsen´ı s pouˇzit´ı stávaj´ıc´ıch technologi´ı (SQL). Vˇsechny entity by v tomto datovém modelu mˇely atributy fromDate a toDate - tyto atributy zde znaˇc´ı ˇcasovou validitu dané poloˇzky (ˇrádku v tabulce). Pˇri kaˇzdé zmˇenˇe záznamu entity se tedy dan´ y z´ aznam vlastnˇe nemˇen´ı, ale jen se zap´ıˇse konec jeho platnosti. Dále se vytvoˇr´ı z´ aznam nov´ y, se stejn´ ymi daty kromˇe zmˇenˇené poloˇzky a s platnost´ı zaˇc´ınaj´ıc´ı od data editace ˇci od data explicitnˇe zadaného. Návrh tohoto ˇreˇsen´ı byl inspirován ˇclánkem [71]. V tomto pˇr´ıpadˇe tedy nemus´ıme pouˇz´ıt ˇzádnou speciáln´ı databázi a návrh modelu je pomˇernˇe jednoduch´ y (pˇrid´ an´ı dvou poloˇzek do kaˇzdé entity jiˇz vytvoˇreného modelu). Vlastn´ı sch´ ema s poloˇ zkami fromDate a toDate (upraveno dle anal´ yzy) lytické ˇc´ asti jsme rozdˇelili informace (z pohledu datového modelu atributy) na:

V ana-

∙ statické a ∙ dynamické. Statick´ y atribut je napˇr´ıklad rok v´ ystavby domu, kter´ y se nem˚ uˇze zmˇenit. Naopak dynamick´ y atribut je napˇr. typ prostoru - z bytu se m˚ uˇze stát nebytov´ y prostor a naopak. Nen´ı tedy nutné poloˇzky fromDate a toDate zaznamenávat u statick´ ych atribut˚ u, je to potˇreba jen u atribut˚ u dynamick´ ych.

4.2.2

Popis zvolen´ e moˇ znosti pro n´ avrh tempor´ arn´ı funkˇ cnosti

Z d˚ uvodu neexistuj´ıc´ı vhodné implementace temporárn´ı databáze jsme vybrali ˇreˇsen´ı postavené na vlastn´ım schématu navrˇzeném v´ yˇse. Pˇri n´ avrhu tempor´ arn´ı funkˇcnosti jsme pak rozliˇsili dvˇe moˇznosti: ∙ klasick´ y objekt s dynamick´ ymi daty (napˇr. d˚ um) - existuj´ı pro nˇej dvˇe entity: Objekt (nehistorick´ a) a ObjektH (historická) a


52

∙ M:N vztahov´ a entita (napˇr. majitel/é domu) - existuje pouze jedna entita, která pˇredstavuje M:N spojen´ı. V pˇr´ıpadˇe prvn´ı moˇznosti datov´ y model obsahuje ke kaˇzdé nehistorické entitˇe dalˇs´ı specia´ln´ı historickou s pˇr´ıdavkem H“ (viz obr´ azek 4.2). Vztah je zde 1:N, tedy mnoho historick´ ych ” entit (ObjektH) pˇr´ısluˇs´ı jedné nehistorické (Objekt). D˚ uleˇzité je, ˇze pro kaˇzdou nehistorickou entitu mus´ı v datab´ azi existovat alespoˇ n jedna odpov´ıdaj´ıc´ı historická. Pokud systém obsahuje historick´ ych entit v´ıce, je nav´ıc nutné, aby na sebe pˇ resnˇ e navazovaly (toDate jedné mus´ı b´ yt právˇe o jeden den menˇs´ı neˇz fromDate navazuj´ıc´ı), v opaˇcném pˇr´ıpadˇe by se jednalo o nekonzistentn´ı stav. Aktu´ aln´ı z´ aznam v H“ tabulce má nastaveno v toDate NULL hodnotu ” a takov´ y záznam m˚ uˇze existovat k dané historické entitˇe jen jeden.

Entita PK

id

EntitaH INTEGER

PK,FK1 PK

statickáInformace1 VARCHAR(45) statickáInformace2 INTEGER

EntitaId fromDate

INTEGER DATETIME

toDate dynamickáInformace1 dynamickáInformace2 dynamickáInformace3

DATETIME VARCHAR(255) DATETIME INTEGER

Obr´ azek 4.2: Entita se statick´ ymi a dynamick´ ymi informacemi. Druhou moˇznost (M:N vztahovou entitu) uvád´ı obrázek 4.3. Tato vztahová entita je jiˇz vlastnˇe historick´ a. Obsahuje totiˇz poloˇzky fromDate a toDate.

EntitaMN EntitaM PK

id

INTEGER

atribut1 atribut2

INTEGER VARCHAR(45)

PK,FK1 PK,FK2 PK

EntitaMId EntitaNId fromDate

INTEGER INTEGER DATETIME

toDate DATETIME dalšíAtribut VARCHAR(45)

EntitaN PK

id

INTEGER

atribut1

VARCHAR(255)

Obr´ azek 4.3: M:N historická entita. Dotazován´ı na stav systému pro urˇcité datum pak prob´ıhá následuj´ıc´ım zp˚ usobem: ∙ vyber vˇsechny poloˇzky, jejichˇz fromDate je menˇs´ı nebo rovno zadanému datu a zároveˇ n toDate je vˇetˇs´ı nebo rovno zadanému datu pro konkrétn´ı datum, ∙ vyber vˇsechny poloˇzky, jejichˇz toDate se rovná NULL pro nejnovˇejˇs´ı poloˇzku/poloˇzky (ty maj´ı vˇzdy toDate nastaveno na NULL). Tyto dotazy n´ am v pˇr´ıpadˇe entity vyjadˇruj´ıc´ı M:N vztah vrát´ı nula aˇz N v´ ysledk˚ u (napˇr. vˇsechny uˇzivatele bytu k danému datu), v ostatn´ıch pˇr´ıpadech (entity s H“ pˇr´ıdavkem) právˇe ” jeden v´ ysledek. Historick´ a entita obsahuje totiˇz dodateˇcná data pro entitu nehistorickou, z tohoto d˚ uvodu mus´ı existovat pro kaˇzdé datum právˇe jedna, v opaˇcném pˇr´ıpadˇe by se jednalo o nekonzistenci datab´ aze.

´ ´ VRSTVA V RAMCI ´ 4.3. DATABAZOV A JAVA EE

53

Pokud se v n´ asleduj´ıc´ı kapitole setkáme s pojmem data ˇci objekty platné pro dané ” datum“, jsou t´ım myˇsleny pr´ avˇe data/objekty, které v´ yˇse uveden´ ymi dotazy pro zadané datum z´ısk´ ame.

4.3

Datab´ azov´ a vrstva v r´ amci Java EE

Abychom plnˇe vyuˇzili moˇznost´ı platformy Java EE, je vhodné pouˇz´ıt techniku tzv. objektovˇerelaˇcn´ıho mapov´ an´ı (ORM). Je to zp˚ usob, kter´ y velmi ulehˇc´ı interakci mezi objektovˇeorientovan´ ym programovac´ım jazykem a relaˇcn´ı databáz´ı. Pokud bychom totiˇz chtˇeli pˇristupovat k datab´ azi pˇr´ımo, naraz´ıme na nˇekolik problém˚ u: ∙ datové typy v datab´ azi mohou b´ yt odliˇsné od datov´ ych typ˚ u v jazyce Java, ∙ objekty v jazyce Java udrˇzuj´ı jak informaci o samotn´ ych datech, tak i o tom, jak´ ym zp˚ usobem m˚ uˇzeme s tˇemito daty pracovat (metody v objektu), relaˇcn´ı databáze oproti tomu udrˇzuje informaci pouze o uloˇzen´ ych datech, ∙ pokud bychom se rozhodli zmˇenit samotnou databázi (napˇr. z MySQL na Apache Derby), byli bychom moˇzn´ a nuceni zmˇenit i veˇskerou komunikaci, protoˇze by se pouˇzit´ı nˇekter´ ych datab´ azov´ ych dotaz˚ u liˇsilo. Vˇsechny v´ yˇse uvedené problémy se snaˇz´ı eliminovat právˇe objektovˇe-relaˇcn´ı mapov´ an´ı, které, zjednoduˇsenˇe ˇreˇceno, mapuje databázové entity (tabulky) na Java tˇr´ıdy. V aplikaˇcn´ı logice pak m˚ uˇzeme pracovat pˇr´ımo s objekty a nemus´ıme se starat o to, jak´ ym zp˚ usobem jsou ve v´ ysledku uloˇzeny v databázi [2]. Nejrozˇs´ıˇrenˇejˇs´ım standardem pro ORM v jazyce Java je Java Persistence API (JPA), aktuálnˇe ve verzi 2.0 [22]. JPA je vyv´ıjené firmou Sun Microsystems. Dalˇs´ım standardem pro objektovˇe-relaˇcn´ı mapov´ an´ı je technologie Java Data Objects (JDO). Pˇri porovnán´ı tˇechto dvou technologi´ı [5] zjist´ıme, ˇze JPA kromˇe nˇekolika drobnost´ı nab´ız´ı podmnoˇzinu funkc´ı JDO. Mimo implementac´ı JPA a JDO existuje i mnoho implementac´ı, které nejsou zaloˇzeny na ˇzádném standardu (napˇr. Apache Cayenne [4]), avˇsak jejich nev´ yhoda je zˇrejmá: pˇri ukonˇcen´ı v´ yvoje projektu bychom byli nuceni mˇenit velkou ˇcást kódu databázové vrstvy z d˚ uvodu pˇrechodu na jin´ y ORM framework. Tato nev´ yhoda u jakékoli implementace JPA/JDO neexistuje, protoˇze pro komunikaci s databáz´ı pouˇz´ıváme standardizované API. Konkrétn´ı ORM framework, kter´ y toto API implementuje, si m˚ uˇzeme pak zvolit libovolnˇe. Z n´ asleduj´ıc´ıch d˚ uvod˚ u se d´ ale zamˇeˇr´ıme pouze na popis implementac´ı JPA a následnˇe jednu z nich vybereme: ∙ oproti nestandardizované ORM technologii má JPA obrovskou v´ yhodu - nejsme nijak z´ avisl´ı na pouˇzit´ı konkrétn´ı JPA implementace, naopak v pˇr´ıpadˇe ukonˇcen´ı v´ yvoje v´ yˇse zm´ınˇeného Apache Cayenne bychom museli celou databázovou vrstvu upravit, ∙ JPA nab´ız´ı sice podmnoˇzinu funkc´ı JDO, ale tato podmnoˇzina je plnˇe dostaˇcuj´ıc´ı, ∙ s pouˇzit´ım JPA m´ am osobnˇe velké zkuˇsenosti, naopak JDO jsem nikdy v takto velkém projektu nepouˇz´ıval.


54

4.3.1

Java Persistence API

Jeˇstˇe pˇred samotn´ ym popisem jednotliv´ ych implementac´ı si nyn´ı popiˇsme nˇekteré základn´ı prvky JPA. Java Persistence API se skl´ adá ze dvou základn´ıch ˇcást´ı: ∙ entity (zm´ınˇené jiˇz v ˇc´ asti 4.1.2.2) jsou tˇr´ıdy, které pˇredstavuj´ı objektovou ˇcást ORM mapován´ı. Nab´ız´ı API pro: – definici prim´ arn´ıch (i sloˇzen´ ych) kl´ıˇc˚ u, – r˚ uzné typy dˇediˇcnosti, – vˇsechny druhy vztah˚ u mezi entitami (one-to-one, one-to-many, many-to-one a také many-to-many), ∙ EntityManager a dalˇs´ı souvisej´ıc´ı tˇr´ıdy pak umoˇzn ˇuj´ı pˇr´ımou práci s databáz´ı jako napˇr´ıklad: – ukl´ ad´ an´ı, maz´ an´ı ˇci u ´pravu entit v databázi, – dotazov´ an´ı do datab´ aze pomoc´ı Java Persistence query language, coˇz je obdoba klasického SQL. Zde pˇredstavuje pro programátora JPA obrovskou v´ yhodu, protoˇze tento dotazovac´ı jazyk je nezávisl´ y jak na pouˇzité implementaci Java Persistence API, tak na pouˇzité databázi, – podpora pro transakce (opˇet nezávislá na zvolené implementaci a databázi). Specifikace JPA je velmi rozs´ ahl´ a a nen´ı pro jej´ı popis v tomto textu dostatek prostoru. Odkáˇzeme proto ˇcten´ aˇre na [50], kde se dozv´ı vˇsechny potˇrebné informace.

4.3.2

Popis a porovn´ an´ı implementac´ı Java Persistence API

Nyn´ı si pˇredstav´ıme nejzn´ amˇejˇs´ı implementace JPA. Je tˇreba zd˚ uraznit, ˇze aˇckoli na konci vybereme jednu z tˇechto implementac´ı, kterou budeme pouˇz´ıvat, nen´ı tento v´ ybˇer tolik d˚ uleˇzit´ y. Kv˚ uli v´ yˇse zm´ınˇené v´ yhodˇe standardu JPA m˚ uˇzeme totiˇz kdykoli jednoduˇse vybran´ y ORM framework zmˇenit za jin´ y bez nutnosti z´ asahu do kódu. EclipseLink Projekt EclipsLink [28] komunity Eclipse (kopnkrétnˇe jeho verze 2.0.0) je dle Sun Microsystems referenˇcn´ı implementac´ı pro JPA 2.0. Splˇ nuje tedy vˇsechny poˇzadavky specifikace a umoˇzn ˇuje nav´ıc napˇr´ıklad pouˇzit´ı XML konfigurace nam´ısto JPA anotac´ı v entitách. Hibernate Framework Hibernate [38] je v oblasti ORM nejznámˇejˇs´ım produktem. Nab´ız´ı jak implementaci JPA, tak i vlastn´ı API (v modulu Hibernate Core) pro objektovˇe-relaˇcn´ı ˇ ast specifikace JPA vych´ mapován´ı. C´ az´ı právˇe z této knihovny Hibernate Core, která vznikla jako prvn´ı a aˇz pozdˇeji byla vytvoˇrena implementace JPA, která je vˇsak také postavena na modulu Hibernate Core. Pouˇzit´ı Hibernate jako implementace pro JPA má tu v´ yhodu, ˇze m˚ uˇzeme pouˇz´ıt i sloˇzitˇejˇs´ı proprietárn´ı API, které Hibernate nab´ız´ı. Nˇekdy se totiˇz m˚ uˇze stát, ˇze programátor potˇrebuje

´ ´ VRSTVA V RAMCI ´ 4.3. DATABAZOV A JAVA EE

55

vyuˇz´ıt nˇejakou funkci, kterou JPA specifikace nepodporuje, ale samotn´ y Hibernate ano. Na druhou stranu, pokud vyuˇzijeme vˇetˇsinu funkc´ı samotného JPA, z˚ ustává zde v´ yhoda (pomˇernˇe) jednoduché pˇr´ıpadné zmˇeny JPA implementace. DataNucleus AccessPlatform Tento produkt [19] je unikátn´ı t´ım, ˇze podporuje opravdu mnoho typ˚ uu ´loˇziˇst’ dat. Nejsme tak omezeni ani relaˇcn´ı databáz´ı, ale m˚ uˇzeme vyuˇz´ıt i databáze objektové. OpenJPA Apache Software Foundation vyv´ıj´ı tuto JPA implementaci [60]. Podporuje vˇsak jen samotnou JPA specifikaci a nepˇridává ˇzádné dalˇs´ı funkce. Dle rychlostn´ıch test˚ u [48] je nav´ıc tato implementace jedna z nejpomalejˇs´ıch. TopLink Tato implementace [83] je u ´zce spjata s projektem EclipseLink, ve kterém se nejv´ıce angaˇzuje firma Oracle. TopLink pak Oracle cel´ y sám vyv´ıj´ı. Vedle Hibernate je TopLink potaˇzmo EclipseLink velmi v´ yznamn´ ym projektem v oblasti objektovˇe-relaˇcn´ıho mapov´ an´ı.

4.3.3

Vybran´ a implementace: Hibernate

Z moˇzn´ ych implementac´ı jsme vybrali framework Hibernate zejména z tˇechto d˚ uvod˚ u: ∙ je to zaveden´ y projekt, kter´ y dokonce stál u zrodu specifikace JPA, ∙ pouˇzijeme sice pouze standardizované Java persistence API, ale pokud bychom pˇri implementaci potˇrebovali pouˇz´ıt nˇejaké speciáln´ı funkce, které nab´ız´ı modul Hibernate Core, nic n´ am v tom nebude bránit, ∙ podle rychlostn´ıch test˚ u [48] je Hibernate jednou z nejrychlejˇs´ıch implementac´ı. Jak jsme vˇsak zm´ınili v´ yˇse, v´ ybˇer této technologie nen´ı nevratn´ y a v pˇr´ıpadˇe, ˇze bychom pˇri implementaci naˇs´ı aplikace narazili na nˇejak´ y problém, proˇc by nemohl b´ yt framework Hibernate pouˇzit, nen´ı problém pouˇz´ıt jinou JPA implementaci.

4.3.4

Datov´ eu ´ loˇ ziˇ stˇ e

Vzhledem k tomu, ˇze jsme se rozhodli pouˇz´ıt objektovˇe-relaˇcn´ı mapován´ı s vyuˇzit´ım JPA, nen´ı moment´ alnˇe v´ ybˇer konkrétn´ıho datového u ´loˇziˇstˇe (databáze) pˇr´ıliˇs d˚ uleˇzit´ y. Pro testov´ an´ı m˚ uˇze b´ yt pouˇzita napˇr´ıklad databáze HyperSQL (HSQLDB) [41], kter´ a nepotˇrebuje v podstatˇe ˇz´ adnou konfiguraci a pro testován´ı je ideáln´ı. Umoˇzn ˇuje dokonce vytvoˇren´ı datab´ aze pouze v operaˇcn´ı pamˇeti, coˇz je velmi v´ yhodné napˇr´ıklad pro unit testy, zejména z d˚ uvodu rychlosti.

56


Kapitola 5

N´ avrh ˇ reˇ sen´ı V této kapitole navrhneme ˇreˇsen´ı na základˇe vybran´ ych technologi´ı z kapitoly pˇredchoz´ı. Nejprve navrhneme datov´ y model celé aplikace, zohledˇ nuj´ıc´ı zejména vybranou technologii pro tempor´ arn´ı datab´ azi, a poté pop´ıˇseme vˇsechny základn´ı funkce aplikaˇcn´ı logiky.

5.1

Datov´ y model

V následuj´ıc´ım textu pop´ıˇseme n´ avrh datového modelu pro cel´ y IS. Cel´ y systém je rozdˇelen do nˇekolika modul˚ u. Pro lepˇs´ı pˇrehlednost budeme datov´ y model popisovat v rámci tˇechto modul˚ u, i kdyˇz se nˇekteré entity objev´ı ve v´ıce modulech zároveˇ n. Je nutné také zm´ınit, ˇze v r´ amci tohoto textu jsou popsány moduly obsahuj´ıc´ı návrh zejména pro funkce prvn´ı (nejvyˇsˇs´ı) priority. Rozdˇelen´ı funkc´ı do priorit jsme provedli v anal´ yze v ˇcásti 3.3.1. Pˇri n´ avrhu datového modelu bylo dodrˇzeno nˇekolik jmenn´ ych konvenc´ı: ∙ pokud m´ a entita ˇc´ıseln´ y identifikátor, je to atribut s názvem id, ∙ identifikaˇcn´ı ciz´ı kl´ıˇc u slabé entity má tvar CiziEntitaId, ∙ ciz´ı kl´ıˇc u standardn´ı entity má tvar CiziEntita, ∙ ostatn´ı atributy zaˇc´ınaj´ı mal´ ym p´ısmenem a dalˇs´ı slova jsou oddˇelena p´ısmenem velk´ ym. Popis jednotliv´ ych modul˚ u se skládá z popisu entit a jejich atribut˚ u. Nezmiˇ nujeme vˇsak vˇzdy vˇsechny atributy, ale sp´ıˇse ty, které potˇrebuj´ı bliˇzˇs´ı vysvˇetlen´ı.

5.1.1

Modul Type

Nejprve si pˇredstavme modul na obrázku 5.1, jehoˇz hlavn´ı sloˇzka je entita AbstractType, která je v ISA hierarchii1 na vrcholu vˇsech konkrétn´ıch typ˚ u, které si pop´ıˇseme v dalˇs´ıch modulech. Typem se v tomto pˇr´ıpadˇe mysl´ı napˇr´ıklad typ domu (kter´ y je uveden na obrázku 5.1), avˇsak typem m˚ uˇze b´ yt také napˇr´ıklad uˇzivatelská role vytváˇrená správcem domu. 1 ISA hierarchie pˇredstavuje v relaˇcn´ı datab´ azi obdobu dˇediˇcnosti v objektovém svˇetˇe. M˚ uˇzeme tak definovat urˇcit´ y nadtyp, kter´ y urˇcuje spoleˇcné atributy vˇsech podtyp˚ u, a pak jednotlivé podtypy, které pˇrid´ avaj´ı nˇekteré dalˇs´ı informace. Typick´ ym pˇr´ıkladem m˚ uˇze b´ yt nadtyp Osoba s podtypy Doktor a Pacient.

57

´ ˇ SEN ˇ Í KAPITOLA 5. NAVRH RE

58

Tyto typy“ maj´ı totiˇz nˇekolik spoleˇcn´ ych rys˚ u. Aplikace m˚ uˇze nab´ıdnout nˇejaké stan” dardn´ı, které mohou vˇsichni z´ akazn´ıci vyuˇz´ıvat (v tomto pˇr´ıpadˇe nen´ı u tohoto AbstractType odkaz na zákazn´ıka - poloˇzka AbstractType.Customer nen´ı vyplnˇena). Takov´ ymto pˇredpˇripraven´ ym typem m˚ uˇze b´ yt napˇr´ıklad uˇzivatelská role správce“ s dan´ ymi právy. Zákazn´ık ” si vˇsak m˚ uˇze vytvoˇrit svoje uˇzivatelské role a t´ım rozˇs´ıˇrit moˇznosti aplikace. Role zapisovatel ” smluv“ m˚ uˇze pak obsahovat pouze pr´ ava na pˇridáván´ı nájemn´ıch smluv. Podobnˇe tento n´ avrh zohledˇ nuje typy, které se t´ ykaj´ı bud’ vˇsech dom˚ u nebo jen tˇech s urˇcit´ ym statutem. Status domu m˚ uˇze b´ yt napˇr´ıklad druˇzstvo“ ˇci spoleˇcenstv´ı vlastn´ık˚ u“ ” ” a jeho pˇresn´ y v´ yznam bude vysvˇetlen v popisu modulu Building. Vzhledem k z´ akazn´ıkovi a statutu domu mohou tedy v systému existovat ˇctyˇri r˚ uzné abstraktn´ı typy: ∙ Customer = NULL a BuildingStatus = NULL - pˇredpˇripraven´ y typ pro vˇsechny zákazn´ıky bez rozd´ılu statutu domu, ∙ Customer != NULL a BuildingStatus = NULL - uˇzivatelsky vytvoˇren´ y typ bez rozd´ılu statutu domu, ∙ Customer = NULL a BuildingStatus != NULL - pˇredpˇripraven´ y typ pro vˇsechny zákazn´ıky pro d˚ um s konkrétn´ım statutem, ∙ Customer != NULL a BuildingStatus != NULL - uˇzivatelsky vytvoˇren´ y typ pro d˚ um s konkrétn´ım statutem.

AbstractType

BuildingStatus PK

id

INTEGER

name description

VARCHAR(45) VARCHAR(255)

PK

id

INTEGER

FK1 FK2

name description BuildingStatus Customer

VARCHAR(45) VARCHAR(255) INTEGER INTEGER

Customer PK

id

INTEGER

description

VARCHAR(255)

BuildingType PK,FK1

AbstractTypeId INTEGER

Obr´ azek 5.1: Datov´ y model modulu Type.

5.1.2

Modul Personal

Vˇsechny entity souvisej´ıc´ı s personalistikou se nacházej´ı v tomto modulu (viz obrázek 5.2). Kl´ıˇcovou funkci zde zastupuje entita UniversalPerson, která je na vrcholu ISA hierarchie a z n´ıˇz dále dˇed´ı dalˇs´ı dvˇe entity, kter´ ymi jsou Firm a Person. Tato ISA hierarchie umoˇzn ˇuje v kterémkoli vztahu pouˇz´ıt UniversalPerson jako univerzáln´ı osobu, která m˚ uˇze pˇredstavovat fyzickou osobu ˇci firmu a kter´ a m˚ uˇze napˇr´ıklad vlastnit d˚ um ˇci byt.

´ MODEL 5.1. DATOVY

59

Ke kaˇzdému kontaktn´ımu u ´daji (entita Contact) univerzáln´ı osoby je uloˇzen jeho typ (ContactType) a hodnota. To umoˇzn ˇuje velmi snadné uchováván´ı r˚ uzn´ ych typ˚ u kontakt˚ u (telefon, e-mail, ICQ) u r˚ uzn´ ych osob.

Address PK

Contact

id

INTEGER

country city street zip streetNumber

VARCHAR(90) VARCHAR(90) VARCHAR(90) INTEGER VARCHAR(20)

ContactType

PK

id

CHAR(10)

FK1 FK2

contactValue VARCHAR(90) UniversalPerson INTEGER ContactType INTEGER

PK,FK1


Firm PK,FK1

name description tradeRN taxID type

UniversalPerson PK

id

FK1 FK2

DomicileAddress INTEGER ContactAddress INTEGER

UniversalPersonId INTEGER

INTEGER

VARCHAR(90) VARCHAR(255) VARCHAR(45) VARCHAR(45) VARCHAR(45) Person

PK,FK1

UniversalPersonId INTEGER personalId firstName lastName

VARCHAR(45) VARCHAR(45) VARCHAR(90)

Obr´ azek 5.2: Datov´ y model modulu Personal.

5.1.3

Modul Building

Tento z´ akladn´ı modul (viz obr´ azek 5.3) obsahuje mnoˇzinu entit pˇr´ımo souvisej´ıc´ıch s domem: ∙ UniversalSpace - nadtyp vˇsech prostor˚ u, v tomto pˇr´ıpadˇe se mysl´ı prostorem jak d˚ um, tak i byt ˇci m´ıstnost, ∙ Building + BuildingH - d˚ um se statick´ ymi a dynamick´ ymi daty: – Address - adresa domu – BuildingStatus - typ domu ve smyslu r˚ uzn´ ych majitel˚ u (napˇr. bytové druˇzstvo“ ” ˇci spoleˇcenstv´ı vlastn´ık˚ u“), pouˇz´ıvá se zejména k rozliˇsen´ı r˚ uzn´ ych vlastnost´ı ” systému na z´ akladˇe r˚ uzn´ ych typ˚ u majitel˚ u, – BuildingType - typ domu ve smyslu stavebn´ım (napˇr. panelov´ y“, cihlov´ y“ apod.), ” ” – ownerUnitCount - nepovinn´ y atribut pro zaznamenán´ı poˇctu vlastnick´ ych jednotek budovy tak, jak jsou zaznamenány v katastru nemovitost´ı, ∙ Space - jak´ ykoli prostor v domˇe, napˇr. byt ˇci garáˇzové stán´ı: – ownerUnitCount - jakou ˇcást vlastnick´ ych jednotek celého domu pˇredstavuje dan´ y prostor,


60

– sharedSpace - pokud je vyplnˇeno, tak znaˇc´ı, ˇze je tento prostor spoleˇcn´ y (napˇr. chodba) a neud´ av´ a se u nˇej tedy vlastnick´ y pod´ıl, ∙ BuildingManager - spr´ avce domu - pro kaˇzd´ y d˚ um mus´ı existovat alespoˇ n jeden, protoˇze má v systému urˇcit´ a pr´ ava, která ostatn´ı osoby nemaj´ı, ∙ ManagerRole - role spr´ avce domu (napˇr´ıklad pˇredseda druˇzstva“), ” ∙ BuildingOwner - vlastn´ık domu, vlastnick´ y pod´ıl je vyjádˇren zlomkem pomoc´ı atribut˚ u shareNumerator a shareDenominator.

Address PK

BuildingStatus

id

INTEGER

PK

country city street zip streetNumber


INTEGER

name description

VARCHAR(45) VARCHAR(255)

PK,FK1 PK

BuildingId fromDate

INTEGER DATETIME

FK2

toDate DATETIME BuildingStatus INTEGER description VARCHAR(255)

Building

ManagerRole PK,FK1

BuildingH

id


UniversalSpace

PK,FK1

UniversalSpaceId

INTEGER

FK2 FK3

builtYear Address BuildingType ownerUnitCount

DATETIME INTEGER INTEGER INTEGER

PK

id

INTEGER

name

VARCHAR(45)

BuildingManager PK,FK1 PK,FK2 PK PK,FK3

UniversalPersonId BuildingId fromDate ManagerRoleId

INTEGER INTEGER DATETIME INTEGER

toDate

DATETIME

Space PK,FK1

UniversalSpaceId

INTEGER

FK2

inventaryId floor Building ownerUnitCount sharedSpace

VARCHAR(45) INTEGER INTEGER INTEGER BIT

BuildingOwner PK,FK1 PK,FK2 PK

UniversalPersonId BuildingId fromDate


toDate shareNumerator shareDenominator

DATETIME INTEGER INTEGER

BuildingType PK,FK1


Obr´ azek 5.3: Datov´ y model modulu Building.

5.1.4

Modul Space

Dalˇs´ım modulem systému je modul Space (obrázek 5.4), jehoˇz obsahem je primárnˇe entita Space + SpaceH, tedy jak uˇz bylo ˇreˇceno, jak´ ykoli prostor v domˇe, kter´ y má definován sv˚ uj typ - SpaceType (napˇr. byt, nebytov´ y prostor ˇci garáˇz). Dále se zde nacházej´ı tyto entity: ∙ Room + RoomH - m´ıstnost nach´ azej´ıc´ı se v bytˇe nebo nebytovém prostoru,

´ MODEL 5.1. DATOVY

61

∙ RoomType - typ m´ıstnosti (napˇr. loˇznice), ∙ SpaceOwner - majitel prostoru s vlastnick´ ym pod´ılem v podobˇe zlomku (stejn´ y zp˚ usob jako v entitˇe BuildingOwner), ∙ SpaceRenter - n´ ajemn´ık prostoru, ∙ SpaceUser - uˇzivatel prostoru - m˚ uˇze se pouˇz´ıt napˇr´ıklad k v´ ypoˇct˚ um plateb za vodu, které z´ avis´ı na poˇctu osob v bytˇe.

SpaceH

SpaceOwner PK,FK1 PK,FK2 PK

SpaceType

UniversalPersonId SpaceId fromDate


PK,FK1 PK

SpaceId fromDate

INTEGER DATETIME

toDate shareNumerator shareDenominator

DATETIME INTEGER INTEGER

FK2

toDate SpaceType description

DATETIME INTEGER VARCHAR(255)

PK,FK1


PK,FK1


RoomType

SpaceRenter PK,FK1 PK,FK2 PK

UniversalPersonId INTEGER SpaceId INTEGER fromDate DATETIME toDate description

Space PK,FK1

UniversalSpaceId

DATETIME VARCHAR(255)

inventaryId floor Building ownerUnitCount sharedSpace

FK2

RoomH

INTEGER VARCHAR(45) INTEGER INTEGER INTEGER BIT

PK,FK1

FK2

RoomId

INTEGER

fromDate toDate RoomType description

DATETIME DATETIME INTEGER VARCHAR(255)

SpaceUser PK,FK1 PK,FK2 PK

Room

UniversalPersonId INTEGER SpaceId INTEGER fromDate DATETIME

UniversalSpace PK

toDate description

DATETIME VARCHAR(255)

id

INTEGER

name

VARCHAR(45)

PK,FK1

UniversalSpaceId

INTEGER

FK2

inventaryId area Space

VARCHAR(45) REAL INTEGER

Obr´ azek 5.4: Datov´ y model modulu Space.

5.1.5

Modul Application

Tento modul (viz obr´ azek 5.5) je v´ıceménˇe oddˇelen od zbytku systému. Slouˇz´ı k uloˇzen´ı uˇzivatelsk´ ych u ´daj˚ u pro vstup do IS. Kaˇzd´ y uˇzivatel (AppUser) má pˇriˇrazenu konkrétn´ı UniversalPerson, ˇc´ımˇz je jasnˇe definováno, jak´ y typ uˇzivatele to je (lze tedy zjistit, ˇze tento uˇzivatel je n´ ajemn´ıkem ˇci vlastn´ıkem bytu apod.). Systém je koncipov´ an tak, aby bylo moˇzno pro kaˇzdého uˇzivatele stanovit povolen´ı pro atomické operace s informacemi (napˇr´ıklad pˇridat majitele“, ukonˇcit nájemn´ı smlouvu“, ” ” pˇridat uˇzivatelsk´ y u ´ˇcet“). To je ˇreˇseno standardnˇe pomoc´ı uˇzivatelsk´ ych rol´ı (UserRole) ” a povolen´ı (Permission). Aby byl vˇsak systém dostateˇcnˇe zabezpeˇcen, je v návrhu jeˇstˇe jedna entita - SecurityRole, coˇz je statick´ a uˇzivatelsk´ a role ve smyslu uˇzivatelsk´ ych skupin v Java EE (viz ˇcást 4.1.2.3),


62

která bude pˇriˇrazena jednotliv´ ym sluˇzb´ am poskytovan´ ym pˇres RPC rozhran´ı. Vˇsechny pouˇzité uˇzivatelské role byly pops´ any v pˇr´ıpadech uˇzit´ı v ˇcásti 3.4.1. Tento návrh tedy poskytne: ∙ základn´ı u ´rovnˇe uˇzivatelsk´ ych rol´ı definované pˇr´ımo na u ´rovni Enterprise Java Beans - nájemn´ık bytu nebude napˇr´ıklad moci pracovat se sluˇzbami upravuj´ıc´ımi informace o domu, ∙ podrobnˇejˇs´ı rozvrstven´ı uˇzivatelsk´ ych rol´ı povoluj´ıc´ıch jednotlivé atomické operace jist´ y pracovn´ık spr´ avcovské firmy bude moci napˇr. pˇridávat nájemn´ı smlouvy, uˇz je ale nebude moci mazat. Jako posledn´ı nebyla jeˇstˇe zm´ınˇena entita Customer. Tuto entitu a dalˇs´ı podrobnosti jiˇz zm´ınˇen´ ych entit si pop´ıˇseme nyn´ı: ∙ Customer - identifikuje z´ akazn´ıka, kter´ y si objednal informaˇcn´ı systém, v entitˇe AppUser mus´ı pak existovat alespoˇ n jeden uˇzivatel s atributem customerAdmin = TRUE, kter´ y zastupuje z´ akazn´ıka pˇri komunikaci s firmou poskytuj´ıc´ı IS, ∙ Permission - mimo informac´ı o operaci, pro kterou je dané povolen´ı, obsahuje odkaz na entitu SecurityRole. Kaˇzdé povolen´ı mus´ı totiˇz obsahovat informaci, v jaké u ´rovni zabezpeˇcen´ı se nach´ az´ı a jakou SecurityRole zpˇresˇ nuje.

UniversalPerson

UserRole

PK

id

INTEGER

FK1 FK2

DomicileAddress INTEGER ContactAddress INTEGER

PK,FK1

Role_has_Permission


PK,FK1 PK,FK2

UserRoleId PermissionId

INTEGER VARCHAR(45)

AppUser PK

FK1 FK2 FK3 FK4

id

Permission

INTEGER

username password UniversalPerson UserRole SecurityRole Customer customerAdmin

VARCHAR(90) VARCHAR(32) INTEGER INTEGER INTEGER INTEGER BIT

PK

internalName

VARCHAR(45)

FK1

name description SecurityRole sortNumber SuperiorPermission


FK2

SecurityRole Customer PK

PK

id

INTEGER

description

VARCHAR(255)

name

VARCHAR(45)

description securityLevel

VARCHAR(255) SMALLINT

Obr´ azek 5.5: Datov´ y model modulu Application.

ˇ Í VRSTVA 5.2. APLIKACN

5.2

63

Aplikaˇ cn´ı vrstva

V této podkapitole se zamˇeˇr´ıme na návrh a popis r˚ uzn´ ych ˇcást´ı aplikaˇcn´ı logiky. Z pohledu serverového modulu naˇs´ı aplikace, kter´ y bude implementován na platformˇe Java Enterprise Edition, je aplikaˇcn´ı (business) logikou myˇslena v´ yhradnˇe Enterprise Java Beans vrstva, tedy jednotlivé EJB tˇr´ıdy a jejich metody.

5.2.1

Z´ akladn´ı operace v tempor´ arn´ı datab´ azi

V ˇcásti 4.2.2 jsme popsali zvolenou moˇznost pro temporárn´ı funkci naˇseho systému a také jsme vysvˇetlili, jak´ ym zp˚ usobem bude prob´ıhat z´ıskáván´ı historick´ ych entit z datab´ aze (jak´ ym zp˚ usobem budou tvoˇreny dotazy). Jednalo se vˇsak pouze o uk´ azku práce s historick´ ymi daty. Nyn´ı si naopak pop´ıˇseme vˇsechny z´ akladn´ı funkce (dle pˇr´ıpad˚ u uˇzit´ı popsan´ ych v podkapitole 3.4), které budou pro práci s entitami z priority (1) implementovány. Následuj´ıc´ı text jeˇstˇe rozdˇel´ıme na funkce pro pr´ aci s: ∙ klasick´ ymi objekty obsahuj´ıc´ı dynamická data a ∙ M:N vztahov´ ymi entitami. Podrobnˇejˇs´ı popis tˇechto dvou variant naleznete v ˇcásti 4.2.2.

5.2.1.1

Operace s klasick´ ymi objekty obsahuj´ıc´ımi dynamick´ a data

Popis funkc´ı rozdˇel´ıme do odstavc˚ u, kde vˇzdy nejprve pop´ıˇseme, co za v´ ysledek daná funkce vrac´ı, a poté to, jaké u ´kony jsou pˇri vykonáván´ı funkce provádˇeny.

get(id, datum) Vr´ at´ı objekt se zadan´ ym identifikátorem, kter´ y je platn´ y pro dané datum. 1. Najdi objekt se zadan´ ym id, 2. k nˇemu pak najdi odpov´ıdaj´ıc´ı ˇrádek v historické entitˇe, kde: (fromDate <= datum) AND ((toDate >= datum) OR (toDate IS NULL))

getHistory(id) Vr´ at´ı kolekci historick´ ych zmˇen objektu se zadan´ ym identifikátorem. Pokud objekt existuje, tato kolekce nem˚ uˇze b´ yt nikdy prázdná (viz ˇcást 4.2.2). 1. Najdi vˇsechny ˇr´ adky historické entity pˇr´ısluˇsej´ıc´ı k objektu se zadan´ ym id.


64

getAll(datum) Vr´ at´ı vˇsechny objekty, které existovaly v zadané datum. 1. Najdi vˇsechny ˇr´ adky historické entity odpov´ıdaj´ıc´ı danému datu: (fromDate <= datum) AND ((toDate >= datum) OR (toDate IS NULL)). Z návrhu plyne, ˇze ve v´ ysledku nemohou existovat dva ˇrádky, které by odpov´ıdaly stejnému z´ aznamu v nehistorické entitˇe, proto m˚ uˇzeme pokraˇcovat takto: 2. ke kaˇzdému takto nalezenému z´ aznamu v historické entitˇe najdi odpov´ıdaj´ıc´ı záznam v entitˇe nehistorické. add(vˇ sechny poloˇ zky objektu) Pˇridá nov´ y objekt se zadan´ ymi poloˇzkami. Kontroluje správné vyplnˇen´ı povinn´ ych poloˇzek. 1. Vytvoˇr nov´ y objekt se statick´ ymi daty a pˇridej ho do databáze, 2. vytvoˇr nov´ y objekt s dynamick´ ymi daty (záznam v H“ entitˇe), ” 3. pˇriˇrad’ tomuto objektu odkaz na objekt se statick´ ymi daty (z bodu 1) a 4. uloˇz ho do datab´ aze. historyUpdate(zmˇ enˇ en´ e poloˇ zky objektu, datum zmˇ eny) Uprav´ı objekt se zachován´ım p˚ uvodn´ıch dynamick´ ych dat v historii (v pˇr´ıpadˇe, ˇze se zmˇenila). Touto metodou je moˇzné upravit jak statick´ a data, tak ta dynamická. 1. Zjisti, zda-li se zmˇenila dynamick´ a data objektu, pokud ano, pokraˇcuj dále, pokud ne, pˇreskoˇc na bod 5, 2. najdi záznam v H“ entitˇe, kter´ y má toDate nastaveno na hodnotu NULL, ” 3. zmˇen ˇ tuto hodnotu na (datum zmˇeny minus jeden den), 4. vytvoˇr v datab´ azi nov´ y z´ aznam v H“ entitˇe se zadan´ ymi zmˇenˇen´ ymi daty (fromDate ” v tomto z´ aznamu je nastaveno na datum zmˇeny, toDate je vyplnˇeno jako NULL), 5. uloˇz zmˇeny nehistorického objektu do databáze. update(zmˇ enˇ en´ e historick´ e poloˇ zky objektu, datum) pro zadané datum.

Oprav´ı historická data objektu

1. Zmˇenˇené poloˇzky jsou aktualizov´ any v záznamu H“ entity, kter´ y je nalezen podle ” zadaného data, 2. m˚ uˇze b´ yt nutno upravit fromDate a/nebo toDate u pˇredchoz´ıho a/nebo následuj´ıc´ıho záznamu v H“ entitˇe, pokud jsou tato data zmˇenˇena v upravovaném záznamu. ” 3. Statická data nemohou b´ yt touto funkc´ı aktualizována.


65

historyRemove(id, substitutiveId) Smaˇze historick´ y záznam pro objekt se zadan´ ym id, prázdné m´ısto je vyplnˇeno“ (pomoc´ı u ´pravy fromDate resp. toDate) objektem se zadan´ ym ” substitutiveId. 1. Najdi, jakému historickému záznamu odpov´ıdá substitutiveId, 2. pokud substitutiveId neidentifikuje pˇredchoz´ı nebo následuj´ıc´ı historick´ y záznam (jenom ty mohou nahradit smazan´ y záznam), neprovádˇej ˇzádnou akci, jinak pokraˇcuj d´ ale: 3. smaˇz historick´ y z´ aznam s identifikátorem id, 4. uprav poloˇzku toDate pˇredchoz´ıho historického záznamu resp. poloˇzku fromDate n´ asleduj´ıc´ıho historického z´ aznamu tak, aby na sebe historické záznamy navazovaly dle poˇzadavku v ˇc´ asti 4.2.2. remove(id) Smaˇze objekt z databáze i s jeho histori´ı. Tato metoda by mˇela b´ yt pouˇz´ıv´ ana pouze v pˇr´ıpadˇe, ˇze byl objekt do databáze uloˇzen omylem nebo má b´ yt u ´plnˇe vyˇrazen z evidence. Pokud vˇsak objekt jiˇz neexistuje (napˇr. p˚ uvodn´ı m´ıstnost v pˇr´ıpadˇe, ˇze se dvˇe m´ıstnosti pˇrestav´ı v jednu), nen´ı ˇzádouc´ı objekt mazat touto funkc´ı. Objekt naopak pouze uprav´ıme funkc´ı historyUpdate a nastav´ıme poloˇzku toDate na datum, kdy byla m´ıstnost zbour´ ana“. ” 1. Smaˇz vˇsechny historické z´ aznamy k objektu s dan´ ym id, 2. smaˇz statick´ y z´ aznam objektu s dan´ ym id. 5.2.1.2

Operace s M:N vztahov´ ymi entitami

Nyn´ı n´ asleduje popis funkc´ı, které se t´ ykaj´ı M:N vztahov´ ych entit. Oproti pˇredchoz´ım se tyto funkce liˇs´ı t´ım, ˇze neexistuje u ´prava objektu, která by nebyla historického charakteru. Je to z toho d˚ uvodu, ˇze tyto M:N vztahové entity (jak bylo zm´ınˇeno v ˇcásti 4.2.2) jsou vlastnˇe entitami historick´ ymi. Z tohoto d˚ uvodu maj´ı také tyto entity sloˇzené primárn´ı kl´ıˇce z identifik´ atoru dvou odkazovan´ ych entit (dále id1“ a id2“) a z poloˇzky fromDate. ” ” get(id1, id2, datum) Vr´ at´ı objekt definovan´ y zadan´ ymi identifikátory, kter´ y existuje pro dané datum. Pozor, objekt nemus´ı existovat. Pokud nen´ı jeden z identifikátor˚ u vyplnˇen, vrát´ı kolekci objekt˚ u, které jsou omezeny zvolen´ ym vyplnˇen´ ym identifikátorem (pouze ten je zahrnut v podm´ınce WHERE). 1. Najdi objekt(y), které odpov´ıdaj´ı podm´ınce zohledˇ nuj´ıc´ı vyplnˇené identifikátory, 2. které nav´ıc splˇ nuj´ı podm´ınku: (fromDate <= datum) AND ((toDate >= datum) OR (toDate IS NULL)).


66

getAll(datum) Vr´ at´ı vˇsechny objekty, které existovaly v zadaném datu. Dotaz nen´ı omezen ˇzádn´ ym z identifik´ ator˚ u. 1. Najdi vˇsechny objekty, které existuj´ı v systému a které splˇ nuj´ı podm´ınku: (fromDate <= datum) AND ((toDate >= datum) OR (toDate IS NULL)). add(vˇ sechny poloˇ zky objektu) Pˇridá nov´ y objekt se zadan´ ymi poloˇzkami. Kontroluje správné vyplnˇen´ı povinn´ ych poloˇzek. 1. Vytvoˇr nov´ y objekt se zadan´ ymi poloˇzkami, 2. pokud je nˇejak´ a z odkazovan´ ych entit historická (existuje také H“ entita), zkontroluj, ” zda-li nepˇrid´ av´ ame objekt, jehoˇz doba platnosti zaˇc´ıná pˇred dobou platnosti prvn´ıho záznamu v odkazované entitˇe (BuildingManager nem˚ uˇze b´ yt napˇr´ıklad správcem domu dˇr´ıv, neˇz byl tento d˚ um postaven), 3. uloˇz objekt do datab´ aze. update(oldId1, oldId2, oldDatum, zmˇ enˇ en´ e poloˇ zky objektu) Tato metoda je ekvivalentem metody update u klasick´ ych objekt˚ u (viz ˇcást 5.2.1.1). Opravuje dynamická data, coˇz jsou v pˇr´ıpadˇe M:N vztahov´ ych entit vˇsechny poloˇzky. Je d˚ uleˇzité podotknout, ˇze zde neexistuje metoda historyUpdate, protoˇze nedává smysl. Pokud chceme zmˇenit napˇr. správce domu, ukonˇc´ıme st´ avaj´ıc´ımu platnost (pomoc´ı této metody) a vytvoˇr´ıme správce nového (pomoc´ı metody add). 1. Vzhledem k tomu, ˇze M:N vztahové entity maj´ı sloˇzené kl´ıˇce a m˚ uˇze se stát, ˇze se pˇri u ´pravˇe zmˇen´ı jeden z kl´ıˇc˚ u, je nejjednoduˇsˇs´ı nejprve smazat pomoc´ı metody remove p˚ uvodn´ı objekt nalezen´ y podle p˚ uvodn´ıch identifikátor˚ u (oldId1, oldId2 a oldDatum) a 2. poté vytvoˇrit objekt nov´ y (pomoc´ı metody add) se zmˇenˇen´ ymi poloˇzkami, které obsahuj´ı i vˇsechny (zmˇenˇené) identifikátory. Obˇe metody mus´ı b´ yt provedeny v transakci. M˚ uˇze se totiˇz st´ at, ˇze metoda add z nˇejakého d˚ uvodu selˇze. Pak mus´ı b´ yt ale v´ ysledek takov´ y, ˇze selhala metoda update, tzn., ˇze p˚ uvodn´ı objekt nem˚ uˇzeme smazat a mus´ı b´ yt proveden rollback2 . remove(id1, id2, datum) Smaˇze objekt z databáze. Stejnˇe, jako bylo uvedeno v´ yˇse, tato metoda se pouˇzije jen v pˇr´ıpadˇe, ˇze chceme dan´ y objekt u ´plnˇe odstranit z evidence. V pˇr´ıpadˇe, ˇze má b´ yt pouze ukonˇcena jeho platnost (napˇr´ıklad vlastn´ık domu jiˇz dan´ y d˚ um nevlastn´ı), zmˇen´ı se jen poloˇzka toDate. 1. Smaˇz objekt dle zadan´ ych identifikátor˚ u z databáze. 2

Datab´ azov´ a operace rollback slouˇz´ı k uveden´ı datab´ aze do nˇejakého pˇredchoz´ıho stavu - napˇr´ıklad do stavu pˇred zapoˇcet´ım transakce v pˇr´ıpadˇe, ˇze nˇejak´ a operace v transakci selhala.


5.2.2

67

Zabezpeˇ cen´ı funkc´ı syst´ emu dle uˇ zivatelsk´ ych pr´ av

Je d˚ uleˇzité zvolit vhodn´ y zp˚ usob pro kontrolu práv pouˇz´ıvan´ ych funkc´ı. Kaˇzdá funkce aplikaˇcn´ı logiky tak mus´ı m´ıt jednoznaˇcnˇe urˇceno, jak´ ym povolen´ım (Permission) mus´ı uˇzivatel disponovat, aby mohl danou funkci pouˇz´ıt. To, ˇze by klientsk´ y modul nemˇel uˇzivateli umoˇznit nepovolené funkce v˚ ubec vyuˇz´ıvat, je vˇec druh´ a. Z naˇseho pohledu vˇsak mus´ıme zajistit, aby tato kontrola zabezpeˇcen´ı probˇehla na u ´rovni serverového modulu. Mus´ıme poˇc´ıtat s t´ım, ˇze napˇr´ıklad webov´ y klientsk´ y modul m˚ uˇze b´ yt upraven u ´toˇcn´ıkem, kter´ y by se pokusil zavolat nepovolenou funkci na serveru. 5.2.2.1

Aspektovˇ e orientovan´ e programov´ an´ı

Pro realizaci v´ yˇse zm´ınˇené kontroly uˇzivatelsk´ ych práv se nab´ız´ı pouˇzit´ı takzvaného aspektovˇe orientovaného programov´ an´ı (AOP). Tato programovac´ı technika umoˇzn ˇuje rozdˇelit kód na aspekty“, coˇz jsou jednotlivé ˇc´ asti programu, které spolu nesouvis´ı a které vykonávaj´ı jednu ” jasnˇe danou funkci [42]. Jako pˇr´ıklad m˚ uˇzeme uvést: ∙ pˇripojen´ı do datab´ aze, ∙ logov´ an´ı ˇci ∙ n´ aˇs pˇr´ıpad kontroly opr´ avnˇen´ı k dané funkci. Pro programovac´ı jazyk Java existuje mnoho framework˚ u nab´ızej´ıc´ıch podporu pro AOP. Nejznámˇejˇs´ım z nich je AspectJ. Technologie Java EE, kterou jsme vybrali v minulé kapitole (v´ıce na stranˇe 46), také nab´ız´ı ˇcásteˇcnou implementaci AOP v podobˇe tzv. interceptor˚ u. Programátor tak m˚ uˇze volán´ı EJB metody obalit“ a spustit k´ od pˇred a/nebo po kaˇzdé metodˇe. T´ımto vlastnˇe danou metodu ve ” v´ ysledku zmˇen´ı, mohli bychom se tedy na tento zp˚ usob také d´ıvat jako na variantu reflexe3 . 5.2.2.2

Pouˇ zit´ı AOP pro kontrolu uˇ zivatelsk´ ych pr´ av

At’ uˇz nakonec naimplementujeme kontrolu uˇzivatelsk´ ych práv jak´ ymkoli aspektovˇe oriento” van´ ym“ zp˚ usobem, tedy pomoc´ı interceptor˚ u na u ´rovni EJB, s vyuˇzit´ım frameworku AspectJ ˇci nˇejakého jiného, princip této implementace z˚ ustane vˇzdy stejn´ y a ten si nyn´ı pop´ıˇseme. Funkci, kterou potˇrebujeme z hlediska AOP pouˇz´ıt, dokumentuje obrázek 5.6. Pˇred spuˇstˇen´ım samotné metody je tˇreba zkontrolovat, zda-li má pˇrihláˇsen´ y uˇzivatel povolen´ı ke spuˇstˇen´ı této metody. Obr´ azek 5.7 pak popisuje, jaké u ´kony provád´ı funkce kontroluj´ıc´ı oprávnˇen´ı uˇzivatele k dané metodˇe: 1. Funkce naˇcte pr´ ava aktu´ alnˇe pˇrihláˇseného uˇzivatele, 2. poté zjist´ı, zda-li tato pr´ ava obsahuj´ı povolen´ı k volán´ı EJB metody: 3

Reflex´ı m´ ame ve svˇetˇe programovac´ıch jazyk˚ u na mysli schopnost programu pˇristupovat k vlastn´ımu k´ odu jako k datovému objektu a z toho vypl´ yvaj´ıc´ı schopnost mˇenit tento sv˚ uj k´ od za bˇehu [57].


68

Spuštění úkonů před voláním metody

AOP část kódu

EJB metoda

Standardní kód v Enterprise Java Bean

Spuštění úkonů po volání metody

AOP část kódu

Obrázek 5.6: Aspektovˇe orientované programován´ı pˇri pouˇzit´ı s Enterprise Java Bean metodou. 3. pokud je povolen´ı nalezeno, AOP ˇc´ ast kódu je dokonˇcena a EJB metoda je standardnˇe spuˇstˇena, 4. pokud vˇsak povolen´ı nalezeno nen´ı, je vyhozena bezpeˇcnostn´ı v´ yjimka a program tedy dále nepokraˇcuje.

Načtení uživatelských práv

[Povolení nenalezeno]

Vyhození výjimky [Povolení nalezeno]

Spuštění metody

Obrázek 5.7: Diagram aktivit pro funkci, která kontroluje oprávnˇen´ı uˇzivatele ke spuˇstˇen´ı EJB metody.

Kapitola 6

Implementace Nyn´ı si pˇredstav´ıme programovou realizaci r˚ uzn´ ych ˇcást´ı naˇseho informaˇcn´ıho systému. Zamˇeˇr´ıme se na nˇekteré problémy, na které jsme pˇri implementaci narazili, a na sloˇzitˇejˇs´ı programové struktury, které stoj´ı za zm´ınku.

6.1

Struktura projektu

Pro v´ yvoj aplikace bylo pouˇzito prostˇred´ı NetBeans 6.8. Aplikace je rozdˇelena do bal´ıˇck˚ u, které uv´ ad´ı tabulka 6.1. cz.fman.is.domain cz.fman.is.server.application cz.fman.is.server.ejb cz.fman.is.server.exception cz.fman.is.shared.exception Tabulka 6.1: Bal´ıˇcky serverového modulu.

∙ domain - obsahuje JPA entity (doménov´ y model databáze) rozdˇelené do podbal´ıˇck˚ u dle modul˚ u navrˇzen´ ych v ˇca´sti 5.1 (napˇr´ıklad podbal´ıˇcky building ˇci space), ∙ server.application - zde se nacházej´ı pomocné tˇr´ıdy, které se vztahuj´ı k aplikaˇcn´ı logice, ale pˇr´ımo ji nevykonávaj´ı, ∙ server.ejb - nejd˚ uleˇzitˇejˇs´ı bal´ıˇcek obsahuj´ıc´ı EJB tˇr´ıdy (v´ıce se o technologii EJB doˇctete v ˇc´ asti 4.1.2.2), ∙ server.exception - soubor v´ yjimek, které se objevuj´ı pouze v serverovém modulu a nen´ı vhodné je propagovat do modulu klientského, ∙ shared.exception - bal´ıˇcek shared obsahuje vˇsechny tˇr´ıdy, u kter´ ych se pˇredpokl´ ad´ a, ˇze se budou pouˇz´ıvat i na klientské stranˇe. Nyn´ı se zde nacház´ı pouze podbal´ıˇcek exception s v´ yjimkami, u kter´ ych se pˇredpokládá, ˇze budou propagovány do klientského modulu.

69

70

KAPITOLA 6. IMPLEMENTACE

6.2

Datab´ azov´ a vrstva

V této ˇcásti probereme nˇekteré detaily z implementace databázové vrstvy. Zm´ın´ıme nˇekteré odliˇsnosti mezi n´ avrhem entit a implementac´ı pomoc´ı JPA. Dále si pop´ıˇseme nˇekteré u ´pravy na základˇe poˇzadavk˚ u klientského modulu a nakonec struˇcnˇe pˇredstav´ıme velmi zaj´ımavou technologii Spring ROO.

6.2.1

Implementaˇ cn´ı rozd´ıly v entit´ ach oproti n´ avrhu

V návrhu m˚ uˇzeme narazit na nˇekolik vztah˚ u 1:1, které v dan´ ych pˇr´ıpadech definuj´ı vlastnˇe ISA hierarchii. Na u ´rovni JPA entit jsou tyto vztahy implementované pomoc´ı dˇediˇcnosti. Následuj´ıc´ı tabulka 6.2 uv´ ad´ı v levém sloupci vˇsechny entity, které odpov´ıdaj´ı tabulkám na vrcholu ISA hierarchie, druh´ y sloupec pak uvád´ı vˇsechny zdˇedˇené entity a ve tˇret´ım sloupci je uveden typ dˇediˇcnosti, kter´ y poté koresponduje s reáln´ ymi tabulkami v databázi. M˚ uˇze m´ıt tyto hodnoty [46]: ∙ SINGLE TABLE - vˇsechny tˇr´ıdy jsou ukládány do jediné tabulky, která má definovány sloupce pro vˇsechny promˇenné vˇsech podtˇr´ıd. Záznam v této tabulce má pak vyplnˇeny sloupce, které odpov´ıdaj´ı dané tˇr´ıdˇe a ostatn´ı sloupce jsou prázdné, ∙ JOINED - tato strategie odpov´ıd´ a pˇresnˇe naˇsemu návrhu databáze - existuje tabulka jak pro spoleˇcnou nadtˇr´ıdu, tak pro vˇsechny podtˇr´ıdy, ∙ TABLE PER CLASS - v této strategii je vytvoˇrena v databázi tabulka pro kaˇzdou konkrétn´ı tˇr´ıdu. Tato tabulka obsahuje vˇsechny promˇenné dané tˇr´ıdy (i ty zdˇedˇené). Typy dˇediˇcnosti byly zvoleny na z´ akladˇe kompromisu mezi rychlost´ı (nejrychlejˇs´ı je strategie SINGLE TABLE, kter´ a nevyˇzaduje ˇzádné speciáln´ı SQL pˇr´ıkazy jako napˇr. JOIN ˇci UNION pro z´ısk´ an´ı z´ aznamu) a poˇzadovan´ ym m´ıstem na disku (nejménˇe m´ısta zab´ırá strategie JOINED). Nadtˇ r´ıda AbstractType

UniversalPerson UniversalSpace

Podtˇ r´ıdy ContactType, BuildingType, ManagerRole, SpaceType, RoomType, UserRole Person, Firm Building, Space, Room

Typ dˇ ediˇ cnosti JOINED

SINGLE TABLE JOINED

Tabulka 6.2: Dˇediˇcnost v JPA entitách.

6.2.2

´ Upravy dle poˇ zadavk˚ u klientsk´ eho modulu

Tato práce popisuje pouze serverov´ y modul tohoto informaˇcn´ıho systému. Funkce, které tento náˇs serverov´ y modul nab´ız´ı, byly testov´ any klientsk´ ym modulem vyv´ıjen´ ym kolegou Petrem Horsk´ ym.

´ ´ VRSTVA 6.2. DATABAZOV A

71

Pˇri pouˇz´ıv´ an´ı objektovˇe-relaˇcn´ıho mapován´ı s implementac´ı Hibernate (tak, jak byla vybrána v ˇc´ asti 4.3.3) se setk´ ame s t´ım, ˇze EJB metoda, která má návratovou hodnotu kupˇr´ıkladu List<Building>, ve skuteˇcnosti vrát´ı konkrétn´ı implementaci rozhran´ı List a v pˇr´ıpadˇe knihovny Hibernate to je PersistentBag. Technologie pouˇz´ıvan´ a v klientském modulu vˇsak nepodporuje pouˇzit´ı této tˇr´ıdy, proto jsme se po domluvˇe s kolegou implementuj´ıc´ım klientsk´ y modul rozhodli pouˇz´ıt technologii GILEAD (Generic Light Entity Adapter) [32]. ´ Uprava pak spoˇc´ıv´ a pouze v tom, ˇze veˇskeré JPA entity mus´ı dˇedit z tˇr´ıdy LightEntity. GILEAD poté zajist´ı spr´ avné fungován´ı komunikace klient-server. Z hlediska naˇseho serverového modulu se jednalo tedy pouze o jednoduchou u ´pravu doménového modelu, která byla provedena na z´ akladˇe poˇzadavku klientského modulu. Je nutné jeˇstˇe zm´ınit, ˇze v dobˇe dokonˇcován´ı tohoto textu jiˇz tato u ´prava doménového modelu nebyla potˇreba, protoˇze s novou verz´ı technologie klientského modulu byla komunikace se serverem upravena tak, aby pouˇzit´ı GILEAD jiˇz nepotˇrebovala.

6.2.3

Spring ROO

V souvislosti s datab´ azovou vrstvou jakékoli Java aplikace jeˇstˇe zmiˇ nme velmi zaj´ımav´ y nástroj, kter´ ym je Spring ROO [74]. Tento nástroj byl v pr˚ ubˇehu v´ yvoje otestován, ale nakonec nebyl pouˇzit. Jedn´ a se o produkt, vytváˇren´ y komunitou Spring, kter´ y velmi ulehˇcuje vytvoˇren´ı struktury Java aplikace, jej´ı databázové vrstvy a dalˇs´ıch souˇcást´ı. Program se ovl´ ad´ a z pˇr´ıkazové ˇrádky a jako ukázku jeho pouˇzit´ı uved’me následuj´ıc´ı k´ od pˇrevzat´ y z [74]: mkdir hello cd hello roo roo> hint roo> project --topLevelPackage com.foo roo> persistence setup --provider HIBERNATE --database HYPERSONIC_IN_MEMORY roo> entity --class ~.Timer --testAutomatically roo> field string --fieldName message --notNull roo> hint controllers roo> controller all --package ~.web roo> selenium test --controller ~.web.TimerController roo> gwt setup roo> perform tests roo> quit Tˇemito pˇr´ıkazy jsme vytvoˇrili kompletn´ı strukturu webové aplikace spolu s JUnit a Selenium testy a dvˇema r˚ uzn´ ymi webov´ ymi moduly. Je vidˇet, ˇze moˇznosti nástroje Spring ROO jsou velmi rozs´ ahlé a pˇri spr´ avném pouˇzit´ı uˇsetˇr´ı programátorovi mnoho ˇcasu.

72


6.3

Aplikaˇ cn´ı logika

Následuj´ıc´ı text se zab´ yv´ a nejpodstatnˇejˇs´ı ˇcást´ı implementace - aplikaˇcn´ı logikou naˇseho informaˇcn´ıho systému.

6.3.1

Uk´ azka funkˇ cn´ıch metod EJB

Funkˇcn´ı metody v EJB tˇr´ıd´ ach tvoˇr´ı z´ akladn´ı kámen aplikaˇcn´ı logiky. Byly implementovány na základˇe návrhu v ˇc´ asti 5.2.1. Jelikoˇz se vˇsak jedn´ a o pomˇernˇe rozsáhlé ˇcásti kódu, odkáˇzeme ˇctenáˇre na pˇr´ılohu C, konkrétnˇe na ˇc´ ast C.1, kde tyto uk´ azky nalezne.

6.3.2

Zabezpeˇ cen´ı funkc´ı dle uˇ zivatelsk´ ych pr´ av

V návrhu ˇreˇsen´ı (v ˇc´ asti 5.2.2) jsme popsali, jak´ ym zp˚ usobem bude zabezpeˇceno volán´ı jednotliv´ ych funkc´ı EJB. Nyn´ı si uk´ aˇzeme konkrétn´ı implementaci této funkce. Byla vytvoˇrena speci´ aln´ı anotace @RequiredPermissions, která definuje mnoˇzinu povolen´ı, z nichˇz alespoˇ n jedn´ım mus´ı pˇrihl´ aˇsen´ y uˇzivatel disponovat, aby mohl provést danou EJB metodu. N´ asleduj´ıc´ı k´ od pˇredstavuje ukázku pouˇzit´ı této anotace pro konkrétn´ı metodu: 1 2 3 4 5

@RolesAllowed({"admin", "superAdmin"}) @RequiredPermissions(EjbPermission.Space_ADD) public void addSpace(SpaceH spaceH) throws DatabaseException { ... } Na prvn´ım ˇr´ adku jsou definov´ any povolené role v rámci Java EE, na druhém ˇrádku je pak pouˇzita naˇse zm´ınˇen´ a anotace, kter´ a v tomto pˇr´ıpadˇe urˇcuje povolen´ı Space ADD“, které ” je potˇreba pro pˇrid´ an´ı prostoru. V ˇcásti 5.2.2.2 jsme popsali, jak´ ym zp˚ usobem je tˇreba kontrolovat tato povolen´ı k jednotliv´ ym metod´ am. Nejjednoduˇsˇs´ı je vyuˇz´ıt tzv. aspektovˇe orientovaného programován´ı (viz ˇcást 5.2.2.1). Jak uˇz bylo zm´ınˇeno v n´ avrhu, Java EE nab´ız´ı pouˇzit´ı tzv. interceptor˚ u, kter´ ymi byla kontrola povolen´ı k EJB metod´ am implementována. Pˇred kaˇzdou EJB metodou je tedy spuˇstˇen interceptor, kter´ y na základˇe naˇs´ı anotace pˇr´ısluˇsej´ıc´ı dané metodˇe zkontroluje uˇzivatelské oprávnˇen´ı. Ukázku pouˇzitého kódu naleznete v pˇr´ıloze C.

6.3.3

Ostatn´ı funkce aplikaˇ cn´ı logiky

Z funkc´ı aplikaˇcn´ı logiky jeˇstˇe stoj´ı za zm´ınku dvˇe tˇr´ıdy: ∙ EjbHelper obsahuje statické metody, které kontroluj´ı r˚ uzné podm´ınky pˇri práci s databáz´ı. M˚ uˇze to b´ yt napˇr´ıklad kontrola pˇri u ´pravˇe entity UniversalPerson, kdy nen´ı dovoleno upravit entitu takov´ ym zp˚ usobem, aby z p˚ uvodn´ı osoby (Person) vznikla firma (Firm) nebo naopak. D´ ale jsou zde metody, které kontroluj´ı r˚ uzná ˇcasová raz´ıtka a jejich konzistenci pˇri pr´ aci s dynamick´ ymi daty.

ˇ Í LOGIKA 6.3. APLIKACN

73

∙ EntityHelper také obsahuje statické metody, které se vˇsak jiˇz t´ ykaj´ı pouze tˇr´ıd s anotac´ı @Entity. Kontroluje se napˇr´ıklad vyplnˇená hodnota promˇenné, která je oznaˇcena jako povinn´ a (NOT NULL). V´ ysledkem tˇechto kontrol, které byly zm´ınˇeny v´ yˇse, nen´ı ˇzádná návratová hodnota, ale v pˇr´ıpadˇe, ˇze nen´ı dan´ a podm´ınka splnˇena, je vyhozena odpov´ıdaj´ıc´ı v´ yjimka.

6.3.4

V´ yjimky

Jak uˇz jste si mohli pˇreˇc´ıst v ˇc´ asti 6.1, v´ yjimky serverového modulu jsou rozdˇeleny do dvou kategori´ı: 1. v´ yjimky, které by se za standardn´ıch podm´ınek nemˇely objevit a nemˇely by se propagovat do klientského modulu, tedy v´ yjimky nepˇredv´ıdatelné (bal´ıˇcek server.exception), 2. v´ yjimky, jejichˇz vyhozen´ı nemus´ı b´ yt nutnˇe selhán´ım programu, ale sp´ıˇse upozornˇen´ım na nˇejak´ y ˇspatn´ y stav (napˇr´ıklad, pokud chce uˇzivatel pˇridat nov´ y objekt do datab´ aze, kter´ y nem´ a vyplnˇené vˇsechny povinné poloˇzky). Tyto v´ yjimky se nacházej´ı v bal´ıˇcku shared.exception. Obr´ azek 6.1 uv´ ad´ı class diagram prvn´ı mnoˇziny v´ yjimek. Jelikoˇz se jedná o nepˇredv´ıdatelné v´ yjimky, vˇsechny dˇed´ı z nadtˇr´ıdy RuntimeException. Popiˇsme si nyn´ı jednotlivé tˇr´ıdy: ∙ InternalServerException je nadtˇr´ıdou vˇsech nepˇredv´ıdateln´ ych v´ yjimek v aplikaci, ∙ DatabaseInconsistencyException - vyhozena v pˇr´ıpadˇe, ˇze je nalezena nˇejaká nekonzistence v datab´ azi, coˇz m˚ uˇze b´ yt napˇr´ıklad absence jakéhokoli záznamu v H“ tabulce, ” pokud v tabulce se statick´ ymi daty existuje alespoˇ n jeden záznam. V´ıce o moˇznostech nekonzistentn´ıho stavu v souvislosti s funkc´ı ˇcasov´ ych ˇrez˚ u jste se doˇcetli v ˇcásti 4.2.2, ∙ FManSecurityException pˇredstavuje jakékoli poruˇsen´ı bezpeˇcnosti v aplikaci. Moment´ alnˇe se to m˚ uˇze st´ at pouze v pˇr´ıpadˇe volán´ı EJB metody, na kterou nemá pˇrihláˇsen´ y uˇzivatel povolen´ı (je pak vyhozena v´ yjimka RequiredPermissionsException). Na obr´ azku 6.2 je zobrazen class diagram druhé mnoˇziny v´ yjimek. Jelikoˇz se jedn´ a o v´ yjimky, které by mˇely b´ yt adekvátnˇe obslouˇzeny (pomoc´ı bloku try - catch), dˇed´ı vˇsechny z nadtˇr´ıdy Exception. ∙ PropagatedServerException je nadtˇr´ıdou vˇsech v´ yjimek v aplikaci, u kter´ ych se pˇredpokl´ ad´ a, ˇze budou propagovány do klientského modulu (EJB metody, které nˇejakou z tˇechto v´ yjimek vyhazuj´ı, ji maj´ı uvedenou za kl´ıˇcov´ ym slovem throws), ∙ InvalidSessionException znaˇc´ı stav, kdy jiˇz uˇzivatel nen´ı pˇrihláˇsen (m˚ uˇze b´ yt pouˇzito napˇr´ıklad pro odhl´ aˇsen´ı uˇzivatele v pˇr´ıpadˇe naruˇsen´ı bezpeˇcnosti), ∙ DatabaseException je nadtˇr´ıdou vˇsech v´ yjimek, které souvisej´ı s prac´ı s datab´ az´ı. V´ yjimky, které od této tˇr´ıdy dˇed´ı, jsou následuj´ıc´ı:

74


RuntimeException

InternalServerException

DatabaseInconsistencyException

FManSecurityException

TransactionException

RequiredPermissionsException

Obrázek 6.1: Nepˇredv´ıdatelné v´ yjimky serverového modulu, které znaˇc´ı selhán´ı programu. – CannotRemoveException je vyhozena tehdy, pokud chce uˇzivatel odstranit nˇejakou entitu, ale nen´ı to moˇzné z d˚ uvodu zpˇetného odkazu jiné entity. Pokud to explicitnˇe neurˇc´ıme, nem˚ uˇzeme napˇr´ıklad smazat d˚ um, kter´ y obsahuje nˇejaké prostory, – CannotUpdateException znamená problém pˇri pˇridáván´ı nebo u ´pravˇe entity (napˇr´ıklad z d˚ uvodu nevyplnˇen´ı vˇsech potˇrebn´ ych pol´ı), – EntityNotFoundException je vyhozena v pˇr´ıpadˇe, ˇze chceme zobrazit nˇejaké závislé objekty (napˇr´ıklad prostory v domˇe), ale zadan´ y objekt (v tomto pˇr´ıpadˇe tedy d˚ um) nebyl nalezen. Podobn´ y pˇr´ıpad je u mazán´ı entity, která v databázi neexistuje, ∙ ServerErrorException je obecnou v´ yjimkou, která znamená jakékoli jiné selhán´ı na serveru, které nepatˇr´ı do ˇz´ adné z v´ yˇse uveden´ ych kategori´ı. Pomoc´ı interceptoru (podobnˇe jako je zajiˇstˇena kontrola uˇzivatelsk´ ych práv) se zachytává jakákoli v´ yjimka typu RuntimeException pˇri prov´ adˇen´ı EJB metody, která je obalena do naˇs´ı v´ yjimky ServerErrorException, a propagována do klientského modulu.

6.4

Napojen´ı rozd´ıln´ ych klientsk´ ych modul˚ u

Nyn´ı zm´ın´ıme nˇekteré moˇznosti napojen´ı klientsk´ ych modul˚ u, které mohou vyuˇz´ıvat funkce, jeˇz tento serverov´ y modul nab´ız´ı. To, ˇze jsme pouˇzili technologii Enterprise Java Beans

´ ´ ˚ 6.4. NAPOJENÍ ROZDÍLNYCH KLIENTSKYCH MODULU

75

Exception

PropagatedServerException

InvalidSessionException

CannotRemoveException

DatabaseException

CannotUpdateException

ServerErrorException

EntityNotFoundException

Obrázek 6.2: V´ yjimky serverového modulu, které jsou propagovány do modulu klientského. v rámci Java Enterprise Edition splˇ nuje zadán´ı z hlediska poskytnut´ı rozhran´ı pro RPC komunikaci. EJB technologie totiˇz vyuˇz´ıvá Java Remote Method Invocation, coˇz je objektov´ a verze vzd´ aleného vol´ an´ı procedur. V r˚ uzn´ ych typech klient˚ u se vˇsak pouˇzit´ı EJB m˚ uˇze liˇsit. Ukaˇzme si proto nyn´ı komunikaci klient-server ve tˇrech z´ akladn´ıch typech klient˚ u. Webov´ a aplikace Nejbˇeˇznˇejˇs´ım dneˇsn´ım typem klienta EJB modulu je webová aplikace. Pokud je spolu s EJB modulem nasazena na server jako EAR1 aplikace, je pouˇzit´ı EJB metod velmi jednoduché (mluv´ıme nyn´ı o EJB 3.0, protoˇze jak jsme zm´ınili v ˇcásti 4.1.2.2, neexistuje dnes jedin´ y d˚ uvod pouˇz´ıvat nˇejakou z pˇredchoz´ıch verz´ı). Pokud tedy chceme napˇr´ıklad v servletu vyuˇz´ıt funkci poskytovanou na u ´rovni Enterprise Java Beans, staˇc´ı n´ am definovat promˇennou s typem daného EJB rozhran´ı a s anotac´ı @EJB: @EJB private BuildingLocal buildingEjb; Pro zavol´ an´ı EJB metody pak nap´ıˇseme následuj´ıc´ı: buildingEjb.addBuilding(...); 1

Enterprise Archive (zkr´ acenˇe EAR) je form´ at souboru pouˇz´ıvan´ y platformou Java EE pro zabalen´ı jednoho nebo v´ıce modul˚ u enterprise aplikace do jediného souboru.

76


Pokud by vˇsak nebyly webov´ y a EJB modul nasazeny na server jako jediná aplikace, bylo by nutné pouˇz´ıt stejn´ y zp˚ usob jako v pˇr´ıpadˇe pˇripojen´ı desktopové aplikace (viz dále). Desktopov´ a aplikace (tlust´ y klient) V desktopové aplikaci je nutné pouˇz´ıt jin´ y zp˚ usob pro vyhledán´ı EJB rozhran´ı. Anotace @EJB m˚ uˇze b´ yt pouˇzita jen v pˇr´ıpadˇe, ˇze je klientsk´ y modul souˇcást´ı aplikace, kde se nach´ az´ı i modul EJB. Nejprve mus´ıme vytvoˇrit soubor jndi.properties a dát ho do naˇs´ı classpath. Obsah souboru bude v pˇr´ıpadˇe aplikaˇcn´ıho serveru JBoss následuj´ıc´ı: 1 2 3

java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces java.naming.provider.url=http://muj.server.cz:1099 D˚ uleˇzit´ y je tˇret´ı ˇr´ adek, kter´ y definuje adresu serveru, na kterém je spuˇstˇen serverov´ y EJB modul. V kódu aplikace pak pro nalezen´ı daného EJB rozhran´ı zavoláme tento kód:

1 2 3 4 5 6 7 8 9 10

private Context context; ... try { context = new InitialContext(); BuildingBeanRemote buildingEjb = (BuildingBeanRemote) context.lookup( "BuildingBean/remote"); } catch (NamingException e) { ... } buildingEjb.addBuilding(...); Vˇsimnˇete si rozd´ılu pouˇzitého rozhran´ı poskytuj´ıc´ıho dané metody. V pˇr´ıpadˇe, ˇze jsou EJB modul i jeho klient (napˇr. webov´ y modul) souˇcást´ı jedné aplikace a jsou spuˇstˇeny na 2 stejném Java Virtual Machine , m˚ uˇzeme pouˇz´ıt rozhran´ı Local, v opaˇcném pˇr´ıpadˇe (jako napˇr´ıklad u desktopové aplikace) mus´ıme vyuˇz´ıt rozhran´ı Remote a komunikace pak prob´ıhá pomoc´ı RMI. V´ıce se o tˇechto rozhran´ıch dozv´ıte v [46]. Mobiln´ı aplikace Vzhledem k tomu, ˇze Java platforma pro mobiln´ı telefony (J2ME) nepodporuje funkce z bal´ıˇcku javax.naming (kter´ y obsahuje napˇr. tˇr´ıdu Context pouˇzitou v´ yˇse), nen´ı moˇzné pouˇz´ıt EJB metody pˇr´ımo. Nab´ız´ı se nˇekolik variant: ∙ zveˇrejnit EJB tˇr´ıdy jako webové sluˇzby a ty pak pouˇz´ıvat v mobiln´ı aplikaci (napˇr´ıklad pomoc´ı knihovny kSOAP 2 [51]), ∙ vytvoˇrit speci´ aln´ı servlet, kter´ y bude obsluhovat volán´ı z mobiln´ıho zaˇr´ızen´ı a bude pˇrepos´ılat“ poˇzadavky EJB metodám a v´ ysledky bude vracet v HTTP odpovˇedi, ” ∙ upravit webovou aplikaci pro pouˇzit´ı v mobiln´ım zaˇr´ızen´ı. 2

V´ yznam Java Virtual Machine je vysvˇetlen v ˇca ´sti 2.5.1

´ 6.5. SPRAVA PROJEKTU

77

Zaj´ımav´ a je posledn´ı moˇznost, která disponuje velkou v´ yhodou oproti ostatn´ım - pˇri v´ yvoji klientské webové aplikace by staˇcilo optimalizovat jej´ı zobrazen´ı i pro mobiln´ı zaˇr´ızen´ı a odpadla by tak nutnost v´ yvoje samostatné mobiln´ı aplikace. Dnes, s rozvojem HTML 5, je tato alternativa stále ˇcastˇejˇs´ı a moˇzná se doˇckáme chv´ıle, kdy v´ yvoj nativn´ıch mobiln´ıch aplikac´ı jiˇz nebude v˚ ubec potˇreba.

6.5

Spr´ ava projektu

Pˇri v´ yvoji jakékoli rozs´ ahlejˇs´ı aplikace, jakou dozajista informaˇcn´ı systém popisovan´ y v této práci je, je d˚ uleˇzité cel´ y projekt vhodnˇe spravovat. Existuje ˇrada nástroj˚ u, které nám mohou tuto pr´ aci usnadnit, pokud je správnˇe pouˇz´ıváme. Popiˇsme si tedy nyn´ı dva hlavn´ı nástroje, které jsou pouˇzity ke spr´ avˇe naˇs´ı aplikace.

6.5.1

Subversion

Prvn´ım z nich je Apache Subversion [7] [17] (zkrácenˇe SVN) - nejrozˇs´ıˇrenˇejˇs´ı nástroj pro verzov´ an´ı soubor˚ u. Mohlo by se zdát, ˇze pˇri v´ yvoji aplikace jedn´ım programátorem nen´ı ˇzádn´ y systém pro verzov´ an´ı soubor˚ u potˇreba, opak je vˇsak pravdou. Nehledˇe na to, ˇze se poˇc´ıtá v budoucnu s rozˇs´ıˇren´ım t´ ymu programátor˚ u. At’ uˇz pro samostatného programátora nebo pro t´ ym v´ yvojáˇr˚ u nab´ız´ı tento systém ˇradu v´ yhod: ∙ pˇri spr´ avném potvrzov´ an´ı zmˇen se m˚ uˇzeme jednoduˇse vrátit k pˇredchoz´ı verzi jednoho nebo vˇsech soubor˚ u, ∙ SVN pln´ı u ´lohu z´ alohov´ an´ı - pouˇzijeme-li Subversion na nˇejakém vzdáleném serveru, m´ ame po kaˇzdém potvrzen´ı zmˇen jistotu, ˇze jsou data spolehlivˇe uloˇzena, ∙ pˇri pr´ aci v t´ ymu program´ ator˚ u je nutné nˇejak sluˇcovat zmˇeny v kódu, které mohou vyvolat konflikty (dva lidé uprav´ı stejn´ y soubor ˇci dokonce stejn´ y ˇrádek, ale kaˇzd´ y jin´ ym zp˚ usobem), k vyˇreˇsen´ı tˇechto konflikt˚ u disponuje SVN speciáln´ımi funkcemi, ∙ SVN také nab´ız´ı jednoduch´ y zp˚ usob pro uchováván´ı r˚ uzn´ ych verz´ı stejného projektu (verz´ı je nyn´ı myˇslena napˇr. verze 1.0, 2.0 apod.), ale i testovac´ıch verz´ı (napˇr. pro testov´ an´ı nové technologie), ∙ vˇsechna modern´ı v´ yvojov´ a prostˇred´ı (napˇr. NetBeans ˇci Eclipse) maj´ı podporu pro SVN. 6.5.1.1

Z´ akladn´ı pojmy

Abychom porozumˇeli pouˇzit´ı SVN, potˇrebujeme znát nˇekteré základn´ı pojmy, které si nyn´ı pop´ıˇseme. Revize je urˇcit´ y stav repozitáˇre3 , kter´ y definuje verze vˇsech soubor˚ u a adresáˇr˚ u. Operace svn commit vˇzdy vytv´ aˇr´ı novou revizi. Touto operac´ı m˚ uˇze b´ yt zmˇenˇen jak´ ykoli poˇcet 3

Repozit´ aˇrem je myˇsleno fyzické um´ıstˇen´ı dat pro Subversion. M˚ uˇze to b´ yt vzd´ alen´ y server, ale i lok´ aln´ı disk.

78


soubor˚ u a adres´ aˇr˚ u. D˚ uleˇzité je, ˇze i pˇri zmˇenˇe velkého mnoˇzstv´ı soubor˚ u je tato operace atomická4 . Pracovn´ı kopie je lok´ aln´ı kopie projektu z repozitáˇre (stav soubor˚ u s danou reviz´ı). Pokud chceme pracovat s projektem um´ıstˇen´ ym na SVN, provedeme vˇzdy nejprve operaci svn checkout, kter´ a zkop´ıruje obsah repozitáˇre ze zadané adresy URL do poˇc´ıtaˇce a vytvoˇr´ı zde lokáln´ı kopii. Pˇri dalˇs´ı pr´ aci pak uˇz nepouˇz´ıváme pˇr´ıkaz svn checkout, ale svn update, kter´ y jiˇz jen aktualizuje lok´ aln´ı kopii dle stavu v repozitáˇri. Lokáln´ı kopie souboru m˚ uˇze b´ yt v r˚ uzn´ ych stavech [17] (zapisov´ ano jako stav lokáln´ıho souboru | stav vzdáleného souboru): ∙ nezmˇenˇena, aktu´ aln´ı - soubor nebyl lokálnˇe zmˇenˇen a oproti pracovn´ı kopii nebyly potvrzeny v repozit´ aˇri ˇz´ adné nové zmˇeny tohoto souboru, operace svn commit ani svn update nezmˇen´ı ˇz´ adné soubory, ∙ lokálnˇe zmˇenˇena, aktu´ aln´ı - soubor byl zmˇenˇen v pracovn´ı kopii, v repozitáˇri je beze zmˇeny, operace svn commit potvrd´ı zmˇeny v repozitáˇri (vytvoˇr´ı novou revizi), operace svn update neudˇel´ a nic, ∙ nezmˇenˇena, neaktu´ aln´ı - soubor v pracovn´ı kopii nebyl zmˇenˇen, ale v repozitáˇri byla potvrzena nov´ a verze tohoto souboru, operace svn commit neudˇelá nic, naopak operace svn update aktualizuje soubor v pracovn´ı kopii na nejnovˇejˇs´ı revizi z repozitáˇre, ∙ zmˇenˇena, neaktu´ aln´ı - soubor byl zmˇenˇen jak v pracovn´ı kopii, tak v repozitáˇri, operace svn commit selˇze s chybou out-of-date“, abychom mohli potvrdit zmˇeny, mus´ıme ” nejprve aktualizovat soubor v pracovn´ı kopii (svn update) - SVN se pokus´ı slouˇcit zmˇeny z repozit´ aˇre se zmˇenami lokáln´ımi, pokud se mu to automaticky nepovede, je nutné pouˇz´ıt pˇr´ıkaz svn resolve a opravit konflikty manuálnˇe. 6.5.1.2

Pouˇ z´ıv´ an´ı Subversion

Subversion nab´ız´ı velmi mnoho funkc´ı, vˇsechny vˇsak zdaleka nemus´ıme vyuˇz´ıt. Popiˇsme si typick´ y pˇr´ıklad pr´ ace program´ atora v t´ ymu spolu s funkcemi, které nejˇcastˇeji pouˇzije [17]: ∙ Program´ ator si zaktualizuje pracovn´ı kopii (svn update), ∙ následnˇe s n´ı pracuje a upravuje soubory, pˇridává je (svn add), maˇze (svn delete), kop´ıruje (svn copy) ˇci pˇresouv´ a (svn move), ∙ dále pracuje se zmˇenˇen´ ymi soubory a m˚ uˇze napˇr´ıklad zjistit, v ˇcem se nyn´ı jeho zmˇeny liˇs´ı od verze v repozit´ aˇri (svn diff) nebo m˚ uˇze pracovn´ı verzi vrátit do stavu zadané revize (svn revert). ∙ Pˇred potvrzen´ım zmˇen m˚ uˇze b´ yt potˇreba slouˇcit zmˇeny v repozitáˇri a pracovn´ı kopii (zmˇeny jsou slouˇceny do pracovn´ı kopie, repozitáˇr z˚ ustává nezmˇenˇen). K tomu slouˇz´ı pˇr´ıkaz svn merge. Pokud toto slouˇcen´ı vytvoˇr´ı nˇejaké lokáln´ı konflikty, m˚ uˇzeme pouˇz´ıt pˇr´ıkaz svn resolve a po manu´ aln´ım opraven´ı pˇr´ıkaz svn resolved. 4

Pokud je nˇejak´ a operace atomick´ a, znamen´ a to, ˇze mus´ı b´ yt provedena bud’ cel´ a nebo nesm´ı b´ yt provedena v˚ ubec. Nem˚ uˇze se tedy st´ at, ˇze pokud dojde v p˚ ulce operace k nˇejaké chybˇe, budou provedeny vˇsechny u ´kony, které se nach´ azely pˇred touto chybou, ale uˇz nebudou provedeny ty, které by n´ asledovaly po chybˇe. V tomto pˇr´ıpadˇe se mus´ı zajistit, ˇze se neprovedou u ´kony ˇza ´dné (cel´ a operace je tedy oznaˇcena jako neproveden´ a).


79

∙ Na z´ avˇer potvrd´ı program´ ator zmˇeny kódu pˇr´ıkazem svn commit. Pokud chceme SVN pouˇz´ıvat se vˇsemi jeho v´ yhodami, je d˚ uleˇzité správnˇe vytvoˇrit strukturu naˇseho repozit´ aˇre. Skl´ ad´ a se z nˇekolika adresáˇr˚ u: ∙ trunk - nejd˚ uleˇzitˇejˇs´ı adres´ aˇr, kter´ y bude repozitáˇr vˇzdy obsahovat. Obsahuje pracovn´ı verzi projektu s nejnovˇejˇs´ımi soubory. Pokud si programátor vytváˇr´ı pracovn´ı kopii, je to kopie pr´ avˇe tohoto adresáˇre. ∙ branches - pokud projekt dospˇeje do stádia, kdy je vhodné kopii projektu uloˇzit jako samostatnou ˇc´ ast, uloˇz´ı se tato verze do adresáˇre branches, konkrétnˇe napˇr´ıklad do branches/1.0_dev. Zde se m˚ uˇze verze dále upravovat a nˇekteré opravené chyby napˇr´ıklad zpˇet sluˇcovat s verz´ı v adresáˇri trunk. ∙ tags - V tomto adres´ aˇri jsou vytváˇreny kopie projektu, které by se jiˇz nikdy nemˇely mˇenit. Mohou to b´ yt napˇr´ıklad verze pˇred zmˇenou nˇejaké technologie (pro uchov´ an´ı stavu pˇred touto zmˇenou) ˇci hlavn´ı verze programu (napˇr. 1.0, 2.0).

6.5.2

Apache Maven

Dalˇs´ı technologi´ı, kterou je pro správu projektu v´ yhodné pouˇz´ıt je Apache Maven [6] (d´ ale budeme popisovat v´ yhradnˇe jeho verzi 2). Tento nástroj nab´ız´ı mnoho funkc´ı pro projekty v jazyce Java, jmenujme ty hlavn´ı: ∙ podpora pro vytv´ aˇren´ı projekt˚ u r˚ uzného typu (napˇr. EJB modul, webová aplikace ˇci standardn´ı Java aplikace) d´ıky tzv. archetyp˚ um, které definuj´ı strukturu jednotliv´ ych projekt˚ u, ∙ spr´ ava z´ avislost´ı, tedy knihoven, které dan´ y projekt pouˇz´ıvá - programátor se nemus´ı starat o stahov´ an´ı knihoven z nejr˚ uznˇejˇs´ıch m´ıst, vˇetˇsina knihoven je totiˇz uloˇzena v centr´ aln´ım Maven u ´loˇziˇsti, pˇr´ıpadnˇe v u ´loˇziˇst´ıch, které spravuj´ı pˇr´ımo spoleˇcnosti vytv´ aˇrej´ıc´ı danou knihovnu, ∙ funkce pro pˇreklad, testov´ an´ı i nasazen´ı projektu - vˇetˇsina v´ yvojov´ ych prostˇred´ı pouˇz´ıv´ a 5 pro tyto funkce n´ astroj Apache Ant , Apache Maven nab´ız´ı vˇsak vlastn´ı implementaci zm´ınˇen´ ych funkc´ı (tedy napˇr. build, clean ˇci deploy), ∙ vytv´ aˇren´ı projektu nez´ avislého na v´ yvojovém prostˇred´ı - tato funkce je velmi v´ yhodn´ a, protoˇze nemus´ıme vytv´ aˇret jiˇz ˇzádn´ y NetBeans projekt“ ˇci Eclipse projekt“, vˇzdy ” ” to bude jen Maven projekt“, kter´ y vˇetˇsina dneˇsn´ıch modern´ıch v´ yvojov´ ych prostˇred´ı ” podporuje. 5

V´ıce se o tomto n´ astroji dozv´ıte v [3].

80


6.5.2.1

Project Object Model

Vˇsechny informace, které se vztahuj´ı k Maven projektu jsou uloˇzeny ve speciáln´ım souboru pom.xml, coˇz je tzv. Project Object Model, tedy zkrácenˇe POM [69]. Tento soubor m˚ uˇze u velmi jednoduchého projektu vypadat napˇr´ıklad takto: 1 2 3 4 5 6 7 8 9 10 11

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0 cz.mojedomena.pokus <artifactId>PokusProjekt <packaging>war 1.0-SNAPSHOT Muj pokusny projekt http://maven.apache.org

12 13 14 15 16 17 18 19 20 21

<dependencies> <dependency> junit <artifactId>junit 3.8.1 <scope>test Na ˇrádku 5 aˇz 11 jsou informace o samotném projektu, ˇrádek 14 aˇz 19 pak definuje jednu závislost. Vˇsimnˇeme si tagu <scope>, kter´ y urˇcuje, pro jak´ yu ´ˇcel je závislost pouˇzita, Maven rozliˇsuje tyto moˇznosti (existuj´ı i dalˇs´ı, které vˇsak nejsou tolik pouˇz´ıvány) [6][69]: ∙ compile - standardn´ı volba, knihovna je dostupná ve vˇsech fáz´ıch v´ yvojového cyklu (build, test i deploy), ∙ provided - knihovna je pouˇzita pˇri kompilaci, ale nekop´ıruje se na server pˇri nasazen´ı aplikace, poˇc´ıt´ a se, ˇze implementaci poskytne server (napˇr. Java servlet API), ∙ runtime - knihovna nen´ı pouˇzita pˇri kompilaci, ale pouze v run-time (napˇr. nˇejak´ y JDBC driver), ∙ test - pouˇzit´ı knihovny je z´ uˇzeno pouze na kompilaci test˚ u (napˇr. JUnit). Soubor pom.xml nab´ız´ı spoustu dalˇs´ıch funkc´ı, napˇr´ıklad definici r˚ uzn´ ych plugin˚ u ˇci nastaven´ı test˚ u, na to vˇsak jiˇz nen´ı v tomto textu prostor, dalˇs´ı informace najdete v [6] a [69].


6.5.2.2

81

Struktura Maven projektu

Posledn´ı, co v tomto struˇcném popisu technologie Maven zm´ın´ıme, bude struktura adres´ aˇre obsahuj´ıc´ıho Maven projekt. Tento adresáˇr je vytváˇren automaticky, ale je dobré vˇedˇet, co jednotlivé podadres´ aˇre obsahuj´ı. Strukturu ukazuje obrázek 6.3. src main config filters java resources webapp site test target pom.xml

Obr´ azek 6.3: Struktura adresáˇre Maven projektu. ∙ src/main/java - samotn´ y kód aplikace, ∙ src/main/resources - prostˇredky, které aplikace potˇrebuje (mohou to b´ yt napˇr´ıklad obr´ azky), ∙ src/main/filters - filtry prostˇredk˚ u definovány jako properties soubory6 , ∙ src/main/config - konfiguraˇcn´ı soubory, ∙ src/main/webapp - adres´ aˇr webové aplikace (to, co napˇr´ıklad v NetBeans projektu pˇredstavuje adres´ aˇr WAR) ∙ src/site - soubory potˇrebné k vytvoˇren´ı stránky Maven projektu, coˇz je standardizovan´ a HTML str´ anka s informacemi o daném projektu, ∙ src/test/java - unit testy, ∙ src/test/resources - prostˇredky potˇrebné pouze pro testy (podobné jako u test scope), ∙ src/test/filters - filtry prostˇredk˚ u potˇrebné pouze v pr˚ ubˇehu testován´ı 6

Properties soubory se pouˇz´ıvaj´ı napˇr´ıklad k z´ apisu r˚ uzn´ ych konfiguraˇcn´ıch poloˇzek. Maj´ı speci´ aln´ı form´ at, kdy na kaˇzdém ˇra ´dku je vˇzdy dvojice n´ azev a hodnota oddˇelena od sebe rovn´ıtkem.

82


∙ target - do tohoto adres´ aˇre se ukládaj´ı zkompilované tˇr´ıdy a archivy pˇripravené pro nasazen´ı aplikace.

Kapitola 7

Testov´ an´ı Tato kapitola se zab´ yv´ a testov´ an´ım celé aplikace resp. jej´ıho serverového modulu. Text je rozdˇelen na popis r˚ uzn´ ych moˇznost´ı pro testován´ı Enterprise Java Beans a na v´ ybˇer jedné z nich.

7.1

R˚ uzn´ e zp˚ usoby testov´ an´ı Enterprise Java Beans

Jádrem funkˇcnosti celého serverového modulu jsou jednotlivé Enterprise Java Beans, proto mus´ıme zajistit jejich komplexn´ı otestován´ı. I pˇresto, ˇze je technologie EJB pomˇernˇe star´ a, neexistuje jedin´ y (nejlepˇs´ı) postup pro testován´ı, kter´ y by napˇr´ıklad firma Sun Microsystems, tv˚ urce této technologie, jednoznaˇcnˇe doporuˇcovala. Máme proto na v´ ybˇer dva odliˇsné zp˚ usoby, jak´ ymi m˚ uˇzeme testy provádˇet: ∙ Testov´ an´ı mimo J2EE kontejner1 (Out-of-container), ∙ Testov´ an´ı uvnitˇr J2EE kontejneru (In-container). Tabulka 7.1 uv´ ad´ı porovn´ an´ı tˇechto dvou zp˚ usob˚ u. V tabulce se nacház´ı poloˇzka Postup ” dle Test-Driven development“ (TDD), coˇz je technika v´ yvoje softwaru. Tradiˇcn´ı testovac´ı metody vych´ azej´ı z pˇredpokladu, ˇze pokud chceme nˇeco otestovat, mus´ıme nejprve napsat alespoˇ n nˇejakou implementaci dané funkce. TDD jde pˇresnˇe opaˇcn´ ym smˇerem. Program´ ator nejprve nap´ıˇse test (kter´ y samozˇrejmˇe v prvn´ı chv´ıli nem˚ uˇze uspˇet) a aˇz poté nap´ıˇse prvn´ı verzi implementace. Poté m˚ uˇze napsat nov´ y, dokonalejˇs´ı test, kter´ y opˇet neuspˇeje, zdokonalit implementaci a pokusit se znovu o splnˇen´ı testu. V´ıce informac´ı o Test-Driven Development naleznete v [54]. Porovn´ an´ı v tabulce nem˚ uˇzeme vˇsak brát naprosto exaktnˇe, protoˇze kaˇzd´ y typ testov´ an´ı se dˇel´ı na dalˇs´ı varianty. Existuj´ı i varianty, které nelze pˇresnˇe zaˇradit do jedné nebo druhé kategorie. Je nicménˇe d˚ uleˇzité, abychom vybrali správn´ y zp˚ usob testován´ı a pˇr´ıpadnˇe i konkrétn´ı framework, kter´ y n´ am tvorbu test˚ u ulehˇc´ı. V následuj´ıc´ım textu tedy probereme moˇznosti testován´ı EJB v J2EE kontejneru i mimo nˇej. 1

J2EE kontejner je prostˇred´ı, ve kterém je nasazena Java EE aplikace. J2EE kontejnerem je napˇr´ıklad aplikaˇcn´ı server Glassfish ˇci JBoss.

83

´ Í KAPITOLA 7. TESTOVAN

84

Rychlost

Spolehlivost

N´ aroˇ cnost pro program´ atora

Postup dle Test-Driven Development

Ouf-of-container Vysok´ a, srovnatelná s klasick´ ymi JUnit testy, nen´ı tˇreba spouˇstˇet server. Niˇzˇs´ı, nˇekteré chyby se mohou projevit aˇz pˇri spuˇstˇen´ı testu v r´ amci daného kontejneru, coˇz out-of-container testy neodhal´ı (nem˚ uˇzeme zde testovat napˇr. interceptory). Z´ aleˇz´ı na konkrétnˇe zvoleném zp˚ usobu test˚ u, v pˇr´ıpadˇe testov´ an´ı pomoc´ı mock“ ob” jekt˚ u2 je n´ aroˇcnost pomˇernˇe vysok´ a. Out-of-container testován´ı umoˇzn ˇuje vyv´ıjet aplikaci dle principu TDD, tedy napsat nejprve testy (nezávislé na implementaci EJB rozhran´ı), a aˇz pozdˇeji vytvoˇrit implementaci, poté upravit testy, refaktorovat implementaci atd.

In-container N´ızká, je tˇreba spustit aplikaˇcn´ı server, provést deploy (nasazen´ı aplikace), a aˇz poté je moˇzné spustit testy. Zaruˇcená, testován´ı prob´ıhá ve stejném prostˇred´ı, ve kterém bude aplikace poté nasazena.

N´ızká, testy se vytváˇrej´ı podobnˇe jako jakékoli jiné unit testy.

V pˇr´ıpadˇe in-container testován´ı je postup dle TDD v podstatˇe nemoˇzn´ y, spouˇstˇen´ı test˚ u je velmi pomalé a testy mohou b´ yt závislé napˇr´ıklad na zvoleném J2EE kontejneru (aplikaˇcn´ım serveru).

Tabulka 7.1: Srovn´ an´ı testov´ an´ı EJB mimo J2EE kontejner a uvnitˇr J2EE kontejneru.

7.1.1

Moˇ znosti out-of-container testov´ an´ı

V tomto pˇr´ıpadˇe m´ ame na v´ ybˇer pouˇzit´ı standardn´ıch JUnit test˚ u s nˇejak´ ym mechanismem, kter´ y nám umoˇzn´ı pracovat s datab´ az´ı mimo kontejner (toto umoˇzn ˇuje napˇr. Hibernate) nebo m˚ uˇzeme vyuˇz´ıt funkc´ı nˇekterého frameworku pro out-of-container testován´ı. Probereme si dva r˚ uzné frameworky, které usnadˇ nuj´ı práci s testy. JBoss Needle Tento projekt [45] je nadstavbou frameworku EasyMock [27]. Nab´ız´ı tedy stejné API pro psan´ı test˚ u jako EasyMock a nav´ıc pˇridává nˇekolik uˇziteˇcn´ ych funkc´ı, napˇr´ıklad speciáln´ı tˇr´ıdu pro spouˇstˇen´ı test˚ u v in-memory3 databázi.

2

Mock objekty jsou velmi uˇziteˇcn´ a technika pro unit testov´ an´ı. M´ısto re´ alné implementace obsahuj´ı pouze nˇejak´ y jednoduch´ y k´ od, kter´ y nevyˇzaduje dalˇs´ı z´ avislosti, jeˇz by se musely v re´ alné implementaci instancovat [55]. 3 Tzv. in-memory datab´ aze nem´ a ˇza ´dné souborové u ´loˇziˇstˇe a veˇsker´ a data jsou uloˇzena pouze v operaˇcn´ı pamˇeti. Tento reˇzim podporuje napˇr. datab´ aze HSQLDB (jak jsme zm´ınili v ˇca ´sti 4.3.4).

˚ E ´ ZPUSOBY ˚ ´ Í ENTERPRISE JAVA BEANS 7.1. RUZN TESTOVAN

85

Ukázka testu: 1 2 3 4 5

@Test public void testSelectAllPerson() throws Exception { createPersons(); //add some test records to in-memory database EasyMock.expect(this.getMock(PersonService.class).saveOrUpdate( (Person) EasyMock.anyObject())).andReturn("success");

6

replayAll(); List all = this.getObjectUnderTest().selectAllPerson(); verifyAll();

7 8 9 10

Assert.assertEquals(5, all.size());

11 12

} Výhody: ∙ pouˇzit´ı EasyMock - programátor se nemus´ı uˇcit nové API, pokud EasyMock zná, ∙ velmi rychlé spouˇstˇen´ı test˚ u v in-memory databázi. Nevýhody: ∙ testov´ an´ı pomoc´ı mock objekt˚ u pˇrináˇs´ı vˇzdy jednu zásadn´ı nev´ yhodu - netestuje se konkrétn´ı implementace, ale pouze se zjiˇst’uje, zda-li byly metody zavolány ve správném poˇrad´ı a se spr´ avn´ ymi n´ avratov´ ymi typy, ∙ jedn´ a se o pomˇernˇe nezabˇehnut´ y projekt, verze 1.0 byla pˇredstavena na zaˇcátku roku 2010. Unitils Projekt Unitils [85] nab´ız´ı ucelené testovac´ı prostˇred´ı. M˚ uˇzeme vyuˇz´ıt velké mnoˇzstv´ı modul˚ u, z nichˇz nˇekteré pouˇz´ıvaj´ı dalˇs´ı extern´ı knihovny: ∙ unitils-mock - framework pro tvorbu mock objekt˚ u, ∙ unitils-inject - podpora pro Dependency Injection4 , ∙ unitils-dbunit - umoˇzn ˇuje pouˇzit´ı funkc´ı projektu DbUnit [21], tedy napˇr´ıklad tzv. DataSetu, coˇz je XML soubor, kter´ y slouˇz´ı pro naplnˇen´ı databáze testovac´ımi daty pˇred libovoln´ ym testem, ∙ unitils-orm - testov´ an´ı za pomoci Hibernate a JPA, ∙ unitils-spring - podpora pro Spring framework, 4

Princip Dependency Injection ˇr´ık´ a, ˇze by tˇr´ıda nemˇela b´ yt z´ avisl´ a na jin´ ych konkrétn´ıch implementac´ıch, ale pouze na abstraktn´ıch tˇr´ıd´ ach ˇci rozhran´ıch. To, jak´ ym zp˚ usobem se dané z´ avislé tˇr´ıdy vyrob´ı a jaké to budou konkrétn´ı implementace, by mˇelo b´ yt jedno. Tato informace by nemˇela b´ yt obsaˇzena v implementaci tˇr´ıdy, ale v nˇejaké celkové konfiguraci aplikace [91].


86

∙ unitils-dbmaintainer - pouˇz´ıv´ a knihovnu DbMaintain [20] umoˇzn ˇuj´ıc´ı správu schématu datab´ aze, ∙ unitils-easymock - integrace s frameworkem EasyMock [27], ∙ unitils-testng - podpora pro testovac´ı framework TestNG [81]. Následuje uk´ azka DataSetu (pojmenovaného napˇr´ıklad City.xml), kter´ y velmi usnadˇ nuje vytvoˇren´ı testovac´ıho prostˇred´ı se zn´ am´ ymi testovac´ımi daty uloˇzen´ ymi v databázi. 1 2 3 4 5 6

Unit testy pak prob´ıhaj´ı standardnˇe: 1. zavolán´ı testované metody z dané EJB tˇr´ıdy 2. kontrola stavu datab´ aze po proveden´ı zmˇen nebo 3. porovnán´ı v´ ysledku z´ıskaného z databáze s v´ ysledkem oˇcekávan´ ym Jmenujme nˇekolik dalˇs´ıch funkc´ı frameworku, které uˇsetˇr´ı programátorovi ˇcas: ∙ anotace @TestedObject - slouˇz´ı pro dependency injection testovaného EJB, ∙ anotace @InjectIntoByType spolu s anotac´ı @PersistenceContext m˚ uˇze b´ yt pouˇzita pro dependency injection tˇr´ıdy EntityManager, ∙ statické metody ReflectionAssert.* slouˇz´ı k jednoduˇsˇs´ımu porovnáván´ı objekt˚ u, nevyuˇz´ıvaj´ı funkce equals(), ale pomoc´ı reflexe porovnávaj´ı skuteˇcn´ y obsah objektu a nab´ızej´ı mnoho dalˇs´ıch uˇziteˇcn´ ych funkc´ı (z nich stoj´ı za zm´ınku napˇr´ıklad porovnán´ı java.util.Collection, kde nez´ aleˇz´ı na poˇrad´ı). Výhody: ∙ velmi ucelené ˇreˇsen´ı pro testov´ an´ı databázov´ ych aplikac´ı, ∙ jednoduché pouˇzit´ı, ∙ jedná se sice o out-of-container testován´ı, ale pˇri pouˇzit´ı spolu s Hibernate testujeme EJB metody mimo kontejner, avˇsak v podstatˇe ve stejném prostˇred´ı (pomoc´ı stejného objektovˇe relaˇcn´ıho mapov´ an´ı), J2EE funkce jako napˇr. interceptory samozˇrejmˇe ale otestovat nem˚ uˇzeme. Nevýhody: ∙ program´ ator se mus´ı uˇcit ˇc´ asteˇcnˇe nové API, to je vˇsak minimáln´ı nev´ yhoda vzhledem k tomu, kolik n´ asledné pouˇzit´ı nov´ ych funkc´ı uˇsetˇr´ı ˇcasu

˚ E ´ ZPUSOBY ˚ ´ Í ENTERPRISE JAVA BEANS 7.1. RUZN TESTOVAN

7.1.2

87

Moˇ znosti in-container testov´ an´ı

V pˇr´ıpadˇe testov´ an´ı uvnitˇr J2EE kontejneru je takˇrka nutné pouˇz´ıt nˇejak´ y framework, kter´ y nám usnadn´ı pr´ aci. V n´ asleduj´ıc´ım textu si pˇredstav´ıme dva nejznámˇejˇs´ı. Cactus Cactus framework [15] nab´ız´ı ucelené ˇreˇsen´ı pro in-container testován´ı. Je zaloˇzen na knihovnˇe JUnit a d´ ale ji rozˇsiˇruje. Pro vytvoˇren´ı testu je nutno rozˇs´ıˇrit jednu z následuj´ıc´ıch tˇr´ıd: ∙ ServletTestCase, ∙ JspTestCase nebo ∙ FilterTestCase. Na obr´ azku 7.1 je zobrazeno schéma, které popisuje fungován´ı frameworku. YYYTestCase na obr´ azku pˇredstavuje nˇekterou z v´ yˇse uveden´ ych tˇr´ıd. Obrázek je zámˇernˇe (pro pˇrehlednost) ponech´ am v angliˇctinˇe.

1

begin() beginXxx()

4 2

3

Redirector Proxy

YYYTestCase 7 8

YYYTestCase 6 5

endXxx() end()

Client side

setUp() testXxx() tearDown()

Server side

Server side classes

Obrázek 7.1: Diagram fungov´ an´ı testovac´ıho frameworku Cactus. Obrázek je pˇrevzat´ y z [15]. Testov´ an´ı kaˇzdé metody testXXX() um´ıstˇené ve tˇr´ıdˇe zdˇedˇené od YYYTestCase pak prob´ıh´ a dle obr´ azku takto: 1. JUnit TestRunner zavol´ a metodu YYYTestCase.runTest(). Pokud existuje metoda begin(WebRequest), je v tomto okamˇziku spuˇstˇena. Parametr WebRequest slouˇz´ı k pˇred´ an´ı r˚ uzn´ ych informac´ı jako napˇr. HTTP hlaviˇcky, HTTP parametr˚ u apod. Metoda runTest() nakonec spust´ı volitelnou metodu beginXXX(WebRequest). 2. Se serverem je nav´ az´ ano HTTP spojen´ı, skrze nˇejˇz Redirector Proxy pˇrijme parametr WebRequest. 3. Redirector Proxy bˇeˇz´ıc´ı na serveru vytvoˇr´ı instanci naˇseho testu a nastav´ı vˇsechny implicitn´ı objekty (promˇenné tˇr´ıdy YYYTestCase).


88

4. Redirector Proxy zavol´ a metody setUp(), testXXX a tearDown um´ıstˇené v naˇsem testu. 5. testXXX() metody spouˇstˇej´ı serverovou aplikaˇcn´ı logiku, která má b´ yt otestována. Vyuˇz´ıvá se standardn´ıch JUnit metod jako napˇr. assert() nebo fail(). 6. Pokud test selˇze, metoda testXXX() vyhod´ı v´ yjimku, která je zachycena v Redirector Proxy. 7. Informace o pˇr´ıpadné v´ yjimce jsou poslány zpˇet na klientskou stranu a v´ yjimka je standardnˇe vytiˇstˇena pomoc´ı knihovny JUnit. 8. Pokud ˇz´ adn´ a v´ yjimka vyhozena nebyla, je zavolána metoda endXXX(WebResponse) (pokud existuje), ve které je moˇzné zkontrolovat informace poslané zpˇet JSP stránkou ˇci servletem. Na konci kaˇzdého testu je zavolána metoda end(). Výhody: ∙ velmi komplexn´ı ˇreˇsen´ı pro in-container testován´ı, ∙ stále se vyv´ıjej´ıc´ı projekt, provˇeˇren´ y mnoha velk´ ymi firmami, ∙ vˇetˇsina pr´ ace je zautomatizov´ ana. Nevýhody: ∙ jelikoˇz potˇrebujeme v naˇsem pˇr´ıpadˇe otestovat pouze EJB tˇr´ıdy, je pouˇzit´ı tohoto frameworku trochu tˇeˇzkop´ adné (je urˇcen pro komplexn´ı testován´ı servlet˚ u, JSP stránek a mimo jin´ e i Enterprise Java Beans), ∙ vˇetˇsinu funkc´ı frameworku bychom nemohli pouˇz´ıt a testován´ı EJB tˇr´ıd by sestávalo z klasického JUnit testov´ an´ı s tou nev´ yhodou, ˇze bychom museli EJB tˇr´ıdy nasadit na server (provést deploy). OpenEJB V tomto pˇr´ıpadˇe se nejedn´ a o framework urˇcen´ y pˇr´ımo k testován´ı, ale o kompletn´ı implementaci aplikaˇcn´ıho serveru podporuj´ıc´ıho EJB 3.0. Nejvˇetˇs´ı vyuˇzit´ı tohoto projektu vˇsak spoˇc´ıv´ a pr´ avˇe v ulehˇcen´ı in-container test˚ u. Aplikaˇcn´ı server lze totiˇz spustit pˇr´ımo v kódu, ideálnˇe tedy v metodˇe setUp(): 1 2 3 4 5 6

private InitialContext initialContext; ... protected void setUp() throws Exception { Properties properties = new Properties(); properties.setProperty(Context.INITIAL_CONTEXT_FACTORY, "org.apache.openejb.client.LocalInitialContextFactory");

7

initialContext = new InitialContext(properties);

8 9

}

´ ZPUSOB ˚ ´ Í 7.2. VYBRANY TESTOVAN

89

Pr˚ ubˇeh testu pak prob´ıh´ a standardnˇe, jako bychom pracovali s aplikac´ı nasazenou na serveru: 1 2

public void testCalculatorViaLocalInterface() throws Exception { Object object = initialContext.lookup("CalculatorImplLocal");

3

assertNotNull(object); assertTrue(object instanceof CalculatorLocal); CalculatorLocal calc = (CalculatorLocal) object; assertEquals(10, calc.sum(4,6)); assertEquals(12, calc.multiply(3,4));

4 5 6 7 8 9

} Výhody: ∙ v´ yborn´ y kompromis mezi rychl´ ymi, ale ménˇe spolehliv´ ymi out-of-container testy a pomal´ ymi testy pˇr´ımo na re´ alném aplikaˇcn´ım serveru, ∙ psan´ı test˚ u je velmi jednoduché, nen´ı potˇreba ˇzádn´ ych speciáln´ıch tˇr´ıd, staˇc´ı základn´ı knihovna JUnit. Nevýhody: ∙ jedn´ a se sice o in-container testován´ı, avˇsak prostˇred´ı, ve kterém jsou testy spouˇstˇené (OpenEJB aplikaˇcn´ı server), neodpov´ıdá pˇresnˇe tomu, ve kterém pak bude projekt nasazen (napˇr. na server Glassfish).

7.2

Vybran´ y zp˚ usob testov´ an´ı

Z uvedeného pˇrehledu je zˇrejmé, ˇze neexistuje ˇzádn´ y ideáln´ı zp˚ usob testován´ı Enterprise Java Beans. Vˇzdy mus´ıme pˇristoupit na nˇejak´ y kompromis. Testy mohou b´ yt velmi rychlé, ale ne tak spolehlivé nebo naopak velice pomalé, ale zaruˇcuj´ıc´ı bezchybné otestován´ı aplikace. Projekt OpenEJB se zd´ a b´ yt pˇr´ıjemn´ ym kompromisem, proto byl pouˇzit pro otestov´ an´ı r˚ uzn´ ych specifick´ ych funkc´ı aplikace (napˇr´ıklad interceptor˚ u), které nemohou b´ yt otestov´ any mimo kontejner. Samotné metody EJB tˇr´ıd byly vˇsak testovány pˇri v´ yvoji pomoc´ı frameworku Unitils [85], coˇz umoˇznilo rychl´ y v´ yvoj ve stylu Test Driven Development.

90


Kapitola 8

Z´ avˇ er 8.1

Zhodnocen´ı v´ ysledk˚ u

Tato diplomov´ a pr´ ace se skl´ ad´ a ze dvou hlavn´ıch ˇcást´ı. Prvn´ı z nich je ˇ c´ ast ryze teoretick´ a a podrobnˇe popisuje vzd´ alené volán´ı procedur, jeho princip, historii i dneˇsn´ı v´ yznam a vybrané dalˇs´ı technologie, které ze vzdáleného volán´ı procedur vycházej´ı. Jedná se zejména o technologii Java RMI, kter´ a byla pouˇzita v implementaˇcn´ı ˇcásti. V druhé ˇc´ asti byl pak na platformˇe Java Enterprise Edition u ´spˇeˇsnˇe implementov´ an serverov´ y modul informaˇ cn´ıho syst´ emu, kter´ y poskytuje prostˇredky pro správu bytov´ ych dom˚ u. Je kladen d˚ uraz na ˇsiroké pouˇzit´ı tohoto systému (podpora pro r˚ uzné typy majitel˚ u jako napˇr. sdruˇzen´ı vlastn´ık˚ u ˇci druˇzstvo) i na unikátn´ı funkci ˇcasov´ ych ˇrez˚ u, kterou v této podobˇe nenajdete v ˇz´ adném konkurenˇcn´ım ˇreˇsen´ı. Tato funkce umoˇzn ˇuje proch´ azet stav dat systému k libovolnému dni v minulosti (jmenujme kupˇr´ıkladu b´ yvalého majitele bytu), ale i v budoucnosti (pokud se zde nach´ azej´ı nˇejaká data - m˚ uˇze to b´ yt napˇr´ıklad budouc´ı nájemn´ık, kter´ y má jiˇz podepsanou smlouvu s nástupem za dva mˇes´ıce). V analytické ˇc´ asti byly probrány poˇzadavky na systém s ohledem na budouc´ı rozˇs´ıˇren´ı. Jsou rozdˇeleny do tˇr´ı priorit, pˇriˇcemˇz implementace byla zamˇeˇrena na funkce priority nejvyˇsˇs´ı. Co je d˚ uleˇzité zm´ınit, tato práce nebere v potaz, jak´ ym zp˚ usobem jsou funkce systému prezentov´ any uˇzivateli a jak´ ym zp˚ usobem s nimi m˚ uˇze pracovat. Tuto ˇcást popisuje kolega Petr Horsk´ y ve své diplomové práci Klientsk´ y modul informaˇcn´ıho systému jako plnohod” notná webov´ a aplikace“, kter´ a se zab´ yvá jedn´ım z moˇzn´ ych klientsk´ ych modul˚ u popisovaného IS. Návrh datového modelu je pak natolik univerzáln´ı, ˇze rozˇs´ıˇren´ı informaˇcn´ıho systému o funkce niˇzˇs´ıch priorit bude velmi jednoduché a nebude vyˇzadovat ˇzádné zásahy do základn´ı struktury datab´ aze. Na u ´rovni datab´ azové vrstvy bylo pouˇzito objektovˇe-relaˇcn´ıho mapován´ı (konkrétnˇe frameworku Hibernate jako implementace Java Persistence API), coˇz je technika, která mapuje datab´ azové entity na standardn´ı Java tˇr´ıdy, a nab´ız´ı programátorovi mnoho v´ yhod plynouc´ıch z tohoto pˇr´ıstupu. Serverov´ y modul poskytuje jakémukoli klientskému modulu rozhran´ı pro volán´ı metod definovan´ ych pomoc´ı technologie Enterprise Java Beans, která je souˇcást´ı platformy Java

91

´ ER ˇ KAPITOLA 8. ZAV

92

Enterprise Edition. Tato klient-server komunikace je pak postavena na Java RMI, coˇz je objektová verze vzd´ aleného vol´ an´ı procedur. Hlavn´ım pˇr´ınosem této pr´ ace je vznik serverového modulu informaˇcn´ıho systému pro správu nemovitost´ı, kter´ y nab´ıdne spolu s klientsk´ ym modulem implementovan´ ym Petrem Horsk´ y velmi komplexn´ı aplikaci s nˇekolika unikátn´ımi funkcemi, jimiˇz ˇzádné stávaj´ıc´ı ˇreˇsen´ı nedisponuje. Nejvˇetˇs´ım pˇr´ınosem pro mˇe je pak zejména z´ıskán´ı zkuˇsenost´ı v oblasti pokroˇcilého programov´ an´ı v jazyce Java. V neposledn´ı ˇradˇe bylo velmi zaj´ımavé vytvoˇrit ucelen´ y dokument popisuj´ıc´ı vzd´ alené vol´ an´ı procedur. Základn´ı princip této technologie je jiˇz velmi star´ y, avˇsak st´ ale aktu´ aln´ı a hojnˇe vyuˇz´ıvan´ y.

8.2

Dalˇ s´ı v´ yvoj aplikace

Serverov´ y modul je plnˇe funkˇcn´ı a nab´ız´ı zejména funkce prvn´ı priority tak, jak byly popsány v anal´ yze. Funkce niˇzˇs´ıch priorit jsou vˇsak také popsány, tud´ıˇz by je bylo vhodné navrhnout a implementovat. Existuje napˇr´ıklad zaj´ımavá moˇznost, která by se nab´ızela po implementaci rozˇsiˇruj´ıc´ıch funkc´ı pro komunikaci (n´ astˇenka, diskuzn´ı fórum apod.). Zákazn´ık˚ um by mohla b´ yt nab´ızena speci´ aln´ı verzi aplikace, která by poskytovala pouze jednoduchou komunikaˇcn´ı platformu pro majitele, n´ ajemn´ıky ˇci sousedy. V listopadu 2010 jsem navˇst´ıvil konferenci Google Developer Day, kde jsem byl podrobnˇe seznámen se sluˇzbou Google App Engine. Tato sluˇzba umoˇzn ˇuje nasazen´ı aplikace na vzdálen´ y server spoleˇcnosti Google (cloud) bez nutnosti jeho konfigurace a správy. Základn´ı pouˇzit´ı dokonce tato firma nab´ız´ı zcela zdarma. Moˇznost provozov´ an´ı aplikace t´ımto zp˚ usobem je velice zaj´ımavá a umoˇzn ˇuje velmi efektivn´ı ˇskálován´ı v´ ykonu. Nˇekolik ˇc´ ast´ı implementace by vˇsak muselo b´ yt upraveno, protoˇze Google App Engine nepodporuje nˇekteré technologie, které byly v implementaci pouˇzity. Z finanˇcn´ıho hlediska by se vˇsak moˇzn´ a tato u ´prava v brzké dobˇe vrátila. Bude ale potˇreba tuto moˇznost podrobnˇe zanalyzovat a zv´ aˇzit vˇsechna pro a proti.

Literatura [1] J. ˚ Akerberg. Distributed Component Object Model. 2005. [2] K. Anuja. Object Relational Mapping. 2008. [3] Apache Ant. http://ant.apache.org. [4] Apache Cayenne. http://cayenne.apache.org. [5] Apache JDO - Which Persistence Specification? http://db.apache.org/jdo/jdo_v_jpa.html. [6] Apache Maven. http://maven.apache.org. [7] Apache Subversion. http://subversion.apache.org. [8] K. P. Birman. Corba: The common object request broker architecture. In Reliable Distributed Systems, pages 119–140. Springer New York, 2005. [9] A. Birrell and B. J. Nelson. Implementing remote procedure calls. ACM Trans. Comput. Syst., 2(1):39–59, 1984. [10] A. D. Birrell, R. Levin, R. M. Needham, and M. D. Schroeder. Grapevine - an exercise in distributed computing. Communications of the ACM, 25(4):260–274, 1982. [11] R. Braden. Requirements for Internet Hosts - Communication Layers. RFC 1122 (Standard), Oct. 1989. Updated by RFCs 1349, 4379. [12] Burlap protocol. http://www.caucho.com/resin-3.0/protocols/burlap.xtp. [13] M. Busch and N. Koch. Rich Internet Applications. 2009. [14] Cactus Domus. http://www.catusdomus.cz. [15] Cactus Test Framework. http://jakarta.apache.org/cactus.

93

94

LITERATURA

[16] P. Chung, Y. Huang, S. Yajnik, D. Liang, J. Shih, C. Wang, and Y. Wang. DCOM and CORBA side by side, step by step, and layer by layer. C++ Report, 10(1):18–30, 1998. [17] B. Collins-Sussman, B. Fitzpatrick, and C. Pilato. Version control with subversion. O’Reilly Media, Inc., 2004. [18] D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON). RFC 4627 (Informational), July 2006. [19] DataNucleus AccessPlatform. http://www.datanucleus.org/products/accessplatform. [20] DbMaintain. http://dbmaintain.sourceforge.net. [21] DbUnit. http://www.dbunit.org. [22] L. DeMichiel. JSR 317: Java Persistence 2.0. http://jcp.org/en/jsr/detail?id=317. [23] P. Denning. The ARPANET after twenty years. American Scientist, 77(6):530–534, 1989. [24] R. Dewsbury. Google web toolkit applications. Prentice Hall, 2007. [25] Distributed object system for Ruby. http://ruby-doc.org/stdlib/libdoc/drb/rdoc/index.html. [26] A. Dubey and D. Wagle. Delivering software as a service. The McKinsey Quarterly, 2007. [27] EasyMock. http://easymock.org. [28] EclipseLink. http://www.eclipse.org/eclipselink. [29] M. Eisler. XDR: External Data Representation Standard. RFC 4506 (Standard), May 2006. [30] R. Fielding. Architectural styles and the design of network-based software architectures. PhD thesis, Citeseer, 2000. [31] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. N´ avrh program˚ u pomoc´ı vzor˚ u. Grada, 2003. [32] Generic Light Entity Adapter. http://noon.gilead.free.fr/gilead. [33] W. Grosso. Java RMI. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2001.

LITERATURA

95

[34] GWT: Communicate with a Server. http://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunication. html. [35] M. Hall. Java: servlety a str´ anky JSP. Neocortex, 2001. [36] M. Henning. The rise and fall of corba. Queue, 4(5):28–34, 2006. [37] Hessian binary web service protocol. http://hessian.caucho.com. [38] Hibernate. http://www.hibernate.org. [39] F. Hoch, M. Kerr, and A. Griffith. Software as a service: Strategic backgrounder. Software & Information Industry Association, 2001. [40] D. Hou and H. Xia. Design of distributed architecture based on java remote method invocation technology. In ESIAT ’09: Proceedings of the 2009 International Conference on Environmental Science and Information Application Technology, pages 618–621, Washington, DC, USA, 2009. IEEE Computer Society. [41] HyperSQL. http://hsqldb.org. [42] J. Irwin, G. Kickzales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, and J. Loingtier. Aspect-oriented programming. Proceedings of ECOOP, IEEE, Finland, pages 220–242, 1997. [43] M. Jakl. Representational State Transfer. [44] Java remote method invocation - distributed computing for java. White paper, Sun Microsystems. http://www.oracle.com/technetwork/java/javase/tech/index-jsp-138781. html. [45] JBoss Needle. http://jbosscc-needle.sourceforge.net/jbosscc-needle/1.0. [46] E. Jendrock, J. Ball, D. Carson, I. Evans, S. Fordin, and K. Haase. The java EE 5 Tutorial. Addison-Wesley, 2006. [47] C. Jensen and R. Snodgrass. Temporal data management. Knowledge and Data Engineering, IEEE Transactions on, 11(1):36–44, 2002. [48] JPA Performance Benchmark. http://www.jpab.org. [49] Json-rpc 1.1 specification. http://json-rpc.org/wd/JSON-RPC-1-1-WD-20060807.html.

96

LITERATURA

[50] M. Keith and M. Schincariol. Pro EJB 3: Java Persistence API. Apress, 2006. [51] kSOAP 2. http://ksoap2.sourceforge.net. [52] A. Lal, J. Formichelli, and C. Pool. The java virtual machine. 1998. [53] S. S. Laurent, E. Dumbill, and J. Johnston. Programming Web Services with XML-RPC. O’Reilly & Associates, Inc., Sebastopol, CA, USA, 2001. [54] L. Linnamaa. Test-Driven Development. In Seminar on Current Trends in Software Industry, Department of Computer Science, University of Helsinki, 2008. [55] T. Mackinnon, S. Freeman, and P. Craig. Endo-testing: unit testing with mock objects. Extreme programming examined, pages 287–301, 2001. [56] M. Mal´ y. Rest: architektura pro webové api. http://zdrojak.root.cz/clanky/rest-architektura-pro-webove-api. [57] J. Malenfant, M. Jacques, and F. Demers. A tutorial on behavioral reflection and its implementation. In Proc. Reflection, volume 96, pages 1–20. [58] G. Mein, S. Pal, G. Dhondu, T. Anand, A. Stojanovic, M. Al-Ghosein, and P. Oeuvray. United states patent no. 7146618. http://www.google.cz/patents?id=7Bt9AAAAEBAJ. [59] O.K. Soft. http://www.oksoft.cz. [60] OpenJPA. http://openjpa.apache.org. [61] Oracle Workspace Manager. http://www.oracle.com/technetwork/database/enterprise-edition/ index-087067.html. [62] D. Panda, R. Rahman, and D. Lane. Ejb 3 in Action. Manning Publications Co., Greenwich, CT, USA, 2007. [63] M. P. Papazoglou. Service-oriented computing: Concepts, characteristics and directions. In WISE, pages 3–12. IEEE Computer Society, 2003. [64] PostgreSQL. http://www.postgresql.org. [65] PostgreSQL - temporal package. http://pgfoundry.org/projects/temporal. [66] Remote Method Invocation (RMI). http://java.sun.com/developer/onlineTraining/rmi/RMI.html.

LITERATURA

97

[67] Remote Python Call. http://rpyc.wikidot.com. [68] M. Slee, A. Agarwal, and M. Kwiatkowski. Thrift: Scalable Cross-Language Services Implementation. 2007. [69] J. Smart. An introduction to maven 2. JavaWorld Magazine., 2005. http://www.javaworld.com/javaworld/jw-12-2005/jw-1205-maven.html. [70] R. Snodgrass. Temporal databases. Theories and Methods of Spatio-Temporal Reasoning in Geographic Space, pages 22–64, 1992. [71] R. Snodgrass. Developing Time-Oriented Database Applications in SQL. 2009. [72] Soap version 1.2. http://www.w3.org/TR/soap12-part1. [73] SOFTWARE 5P. http://www.ofsoft.cz. [74] Spring ROO. http://www.springsource.org/roo. [75] R. Srinivasan. RPC: Remote Procedure Call Protocol Specification Version 2. RFC 1831 (Proposed Standard), Aug. 1995. Obsoleted by RFC 5531. [76] STARLIT, software a sluˇzby pro správu dom˚ u. http://www.starlit.cz. [77] A. Steiner. TimeDB. http://www.timeconsult.com/Software/Software.html. [78] A. Steiner. A generalisation approach to temporal data models and their implementations. PhD thesis, Swiss Federal Institute of Technology Z¨ urich, 1998. [79] Sun Microsystems. RPC: Remote Procedure Call Protocol specification. RFC 1050 (Historic), Apr. 1988. Obsoleted by RFC 1057. [80] Sun Microsystems. RPC: Remote Procedure Call Protocol specification: Version 2. RFC 1057 (Informational), June 1988. [81] TestNG. http://testng.org. [82] R. Thurlow. RPC: Remote Procedure Call Protocol Specification Version 2. RFC 5531 (Draft Standard), May 2009. [83] TopLink. http://www.oracle.com/technetwork/middleware/toplink/overview. [84] K. Torp, C. Jensen, and R. Snodgrass. Stratum approaches to temporal DBMS implementation. In Database Engineering and Applications Symposium, 1998. Proceedings. IDEAS’98. International, pages 4–13. IEEE, 2002.

98

LITERATURA

[85] Unitils. http://www.unitils.org. [86] J. Waldo. Remote procedure calls and java remote method invocation. IEEE concurrency, 6(3):5–7, 1998. [87] Web Service Definition Language. http://www.w3.org/TR/wsdl. [88] T. Wennerstr¨ om, J. Jespersen, and M. Lundquist. Simple Object Access Protocol A basic overview. 2002. [89] J. White. High-level framework for network-based resource sharing. RFC 707, 1975. [90] Xml-rpc home page. http://www.xmlrpc.com. [91] H. Yang, E. Tempero, and H. Melton. An empirical study into use of dependency injection in Java. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on, pages 239–247. IEEE, 2008. [92] Your First Cup: An Introduction to the Java EE Platform. http://download.oracle.com/javaee/6/firstcup/doc/.

Pˇ r´ıloha A

Seznam zkratek OS Operaˇcn´ı systém (Operating System) RPC Remote Procedure Call RMI Remote Method Invocation IS Informaˇcn´ı systém RFC Request for Comments ARPANET Advanced Research Projects Agency Network FTP File Transfer Protocol RJE Remote Job Entry Protocol IT Informaˇcn´ı technologie TCP Transmission Control Protocol IP Internet Protocol XDR External Data Representation Standard NCS Network Computing System DCE/RPC Distributed Computing Environment / Remote Procedure Calls CORBA Common Object Request Broker Architecture DCOM Distributed Component Object Model RIA Rich Internet Applications SaaS Software as a service WSDL Web Service Definition Language SOAP Simple Object Access Protocol

99

100

ˇ ÍLOHA A. SEZNAM ZKRATEK PR

XML Extensible Markup Language HTTP Hypertext Transfer Protocol REST Representational State Transfer API Application programming interface JSON JavaScript Object Notation COM Component Object Model EJB Enteprise Java Bean(s) GWT Google Web Toolkit AMF Action Message Format RPyC Remote Python Call PYRO PYthon Remote Objects DRb Distributed object system for Ruby JVM Java Virtual Machine JDK Java Development Kit (Java) EE (Java) Enterprise Edition JSP Java Server Pages HTML HyperText Markup Language EIS Enterprise Information Systems (T)SQL (Temporal) Structured Query Language DBMS Database Management System ORM Objektovˇe-relaˇcn´ı mapov´ an´ı (Object-relational mapping) JPA Java Persistence API JDO Java Data Objects HSQLDB Hyper Structured Query Language Database ISA Is a AOP Aspektovˇe orientované programován´ı GILEAD Generic Light Entity Adapter SVN Subversion

101

URL Unique Resource Locator POM Project Object Model JDBC Java Database Connectivity J2EE Java 2 Enterprise Edition TDD Test-Driven Development

102

ˇ ÍLOHA A. SEZNAM ZKRATEK PR

Pˇ r´ıloha B

Popis instalace B.1

Java Runtime Environment

Nainstalujte JRE, webové str´ anky: http://www.oracle.com/technetwork/java/javase/downloads.

B.2

Server Glassfish

Nainstalujte aplikaˇcn´ı server Glassfish, webové stránky: http://glassfish.java.net/public/downloadsindex.html.

B.3

Nasazen´ı EJB modulu

V adres´ aˇri cesta_k_instalaci_glassfish/bin se nacház´ı spustiteln´ y soubor asadmin (s pˇr´ıponou dle operaˇcn´ıho systému). Následuj´ıc´ım pˇr´ıkazem nasad’te EJB modul (náˇs serverov´ y modul informaˇcn´ıho systému) na server: asadmin deploy --user jmeno_admina --password heslo_admina cesta_k_souboru/fman-ejb.jar

B.4

Spuˇ stˇ en´ı serveru

Spust’te server Glassfish pˇr´ıkazem: asadmin start-domain domain1 Tento pˇr´ıkaz proved’te v adres´ aˇri, kter´ y byl uveden v pˇredchoz´ım bodˇe (B.3).

103

ˇ ÍLOHA B. POPIS INSTALACE PR

104

B.5

Pˇ ripraven´ y EJB modul

V tomto okamˇziku je EJB modul pˇredstavuj´ıc´ı serverov´ y modul naˇseho informaˇcn´ıho systému pˇripraven k poskytov´ an´ı sluˇzeb klientskému modulu skrze implementované rozhran´ı.

Pˇ r´ıloha C

Uk´ azky k´ odu Nyn´ı si uk´ aˇzeme nˇekteré zaj´ımavé ˇcásti zdrojového kódu. Nejprve to budou vybrané funkˇcn´ı metody EJB, tedy hlavn´ı funkce aplikaˇcn´ı logiky, a poté kontrola uˇzivatelsk´ ych práv pomoc´ı interceptoru.

C.1

Funkˇ cn´ı metody EJB

Metoda pro pˇrid´ an´ı prostoru: 1 2

@RequiredPermissions(EjbPermission.Space_ADD) public void addSpace(SpaceH spaceH) throws DatabaseException {

3 4 5 6

EjbHelper.checkNotNullConstraints(spaceH.getSpace()); userBean.checkLoggedInBuildingManager(spaceH.getSpace() .getBuilding().getId());

7 8 9 10 11 12

EjbHelper.checkNullId(spaceH.getSpace()); EjbHelper.checkNullToDate(spaceH); EjbHelper.checkDependentHistoryEntityFromDate(spaceH, buildingBean.getFirstBuilding(spaceH.getSpace() .getBuilding().getId()));

13 14

UserTransaction ut = ctx.getUserTransaction();

15 16

Space space = spaceH.getSpace();

17 18 19 20 21

try { ut.begin(); em.persist(space); em.flush();

22 23

spaceH.setSpace(space);

105

ˇ ÍLOHA C. UKAZKY ´ ´ PR KODU

106

spaceH.getSpaceHPK().setSpaceId(space.getId()); EjbHelper.checkNotNullConstraints(spaceH); em.persist(spaceH); ut.commit();

24 25 26 27

} catch (CannotUpdateException e) { try { ut.rollback(); } catch (SystemException sysEx) { throw new TransactionException( "Rollback failed: " + sysEx.getMessage()); } throw e; }

28 29 30 31 32 33 34 35 36 37 38 39

} Metoda pro smaz´ an´ı historické zmˇeny prostoru:

1 2 3 4 5

@RequiredPermissions(EjbPermission.Space_UPDATE) public void historyRemoveSpace(SpaceHPK id, SpaceHPK substitutiveSpaceHPK) throws DatabaseException, IllegalStateException { UserTransaction ut = ctx.getUserTransaction();

6 7 8

SpaceH oldSpaceH = this.getSpace(id.getSpaceId(), id.getFromDate()); EjbHelper.checkEntityWasFound(oldSpaceH, SpaceH.class, id);

9 10 11

userBean.checkLoggedInBuildingManager( oldSpaceH.getSpace().getBuilding().getId());

12 13 14

SpaceH beforeOldSpaceH = this.getSpace(oldSpaceH.getSpace().getId(), EjbHelper.getYesterday(oldSpaceH.getFromDate()));

15 16 17 18 19 20

SpaceH afterOldSpaceH = null; if (oldSpaceH.getToDate() != null) { afterOldSpaceH = this.getSpace(oldSpaceH.getSpace().getId(), EjbHelper.getTomorrow(oldSpaceH.getToDate())); }

21 22 23 24 25 26 27

SpaceH substitutiveSpaceH = null; if (substitutiveSpaceHPK != null) { substitutiveSpaceH = this.getSpace(substitutiveSpaceHPK.getSpaceId(), substitutiveSpaceHPK.getFromDate()); EjbHelper.checkEntityWasFound(substitutiveSpaceH, SpaceH.class, substitutiveSpaceHPK);

ˇ Í METODY EJB C.1. FUNKCN

}

28 29

try { ut.begin();

30 31 32

EjbHelper.checkPossibleHistoryEntitySubstitutiveRemove( substitutiveSpaceH, beforeOldSpaceH, afterOldSpaceH); em.remove(oldSpaceH);

33 34 35 36

if ((substitutiveSpaceH != null) && substitutiveSpaceH.equals(beforeOldSpaceH)) { substitutiveSpaceH.setToDate(oldSpaceH.getToDate()); em.merge(substitutiveSpaceH); } else if ((substitutiveSpaceH != null) && substitutiveSpaceH.equals(afterOldSpaceH)) { em.remove(substitutiveSpaceH); em.flush(); substitutiveSpaceH.setFromDate(oldSpaceH.getFromDate()); em.persist(substitutiveSpaceH); } else if (substitutiveSpaceH != null) { throw new CannotUpdateException(oldSpaceH.getClass(), CannotUpdateReason.HISTORY_INCONSISTENCY); }

37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

ut.commit(); } catch (CannotUpdateException e) { try { ut.rollback(); } catch (SystemException sysEx) { throw new TransactionException( "Rollback failed: " + sysEx.getMessage()); } throw e; }

54 55 56 57 58 59 60 61 62 63 64 65 66

} Metoda pro z´ısk´ an´ı vˇsech spr´ avc˚ u domu k danému datu:

1 2 3 4

@RequiredPermissions(EjbPermission.BuildingManager_VIEW) public Collection<BuildingManager> getBuildingManagers( Integer buildingId, Date date) {

107

ˇ ÍLOHA C. UKAZKY ´ ´ PR KODU

108

userBean.checkLoggedInBuildingManager(buildingId); date = EjbHelper.getResolvedDate(date);

5 6 7

Query query = em.createQuery( "SELECT bm FROM BuildingManager bm " + "LEFT JOIN FETCH bm.building" + "LEFT JOIN FETCH bm.universalPerson" + "LEFT JOIN FETCH bm.managerRole " + "WHERE bm.building.id = :buildingId " + "AND ((bm.buildingManagerPK.fromDate" + " <= :date AND bm.toDate >= :date) " + "OR (bm.buildingManagerPK.fromDate" + " <= :date AND bm.toDate IS NULL))"); query.setParameter("buildingId", buildingId); query.setParameter("date", date);

8 9 10 11 12 13 14 15 16 17 18 19 20

List<BuildingManager> buildingManagersList = query.getResultList(); return buildingManagersList;

21 22 23

}

C.2 1

Interceptor na kontrolu uˇ zivatelsk´ ych pr´ av

public class PermissionsCheckInterceptor {

2

@EJB UserLocal userBean;

3 4 5

@AroundInvoke public Object checkPermissions(InvocationContext ctx) throws Exception { RequiredPermissions requiredPermissions = ctx.getMethod() .getAnnotation(RequiredPermissions.class); if (requiredPermissions != null) { for (EjbPermission requiredPermission : requiredPermissions.value()) { if (userBean.userHasPermission(requiredPermission)) { return ctx.proceed(); } }

6 7 8 9 10 11 12 13 14 15 16

throw new InvalidSessionException("User does not have required" + "permissions to perform an action.");

17 18

} return ctx.proceed();

19 20

}

21 22

}

Pˇ r´ıloha D

Obsah pˇ riloˇ zen´ eho CD Pˇriloˇzené CD je rozdˇeleno na tˇri hlavn´ı adresáˇre: ∙ text\ - vlastn´ı text diplomové práce v PDF spolu se zdrojov´ ym kódem v LATEXu a vˇsemi pouˇzit´ ymi obr´ azky, ∙ install\ - soubory pro instalaci a spuˇstˇen´ı aplikace (resp. serverového modulu), ∙ src\ - NetBeans projekt se zdrojov´ ymi kódy. Následuje podrobn´ y v´ ypis obsahu CD: text\ text\dp.pdf text\dp-latex.zip install\ install\fman-ejb src\ src\fman-ejb.zip

109

Serverový modul informačního systému s rozhraním pro

Recommend Documents