České Vysoké Učení Technické Fakulta Elektrotechnická. Diplomová práce. Marek Hudík. Vedoucí práce: Ing. Jan Koutník

ˇ Ceské Vysoké Uˇcení Technické Fakulta Elektrotechnická

Diplomová práce

Vzdálený pˇrístup k simulátoru neuronových sítí Marek Hudík

Vedoucí práce: Ing. Jan Koutník

Studijní program: Informatika a výpoˇcetní technika Obor: Elektrotechnika a informatika, dobíhající, Magisterský leden 2007

ii

Podˇekování Rád bych vyjádˇril své podˇekování každému, kdo mˇe pomohl a morálnˇe podpoˇril bˇehem mé práce, zejména vedoucímu práce ing. Janu Koutníkovi pro jeho cenné poznámky a konzultace (a také své milované veverce za nesmírnou trpˇelivost). Rád bych tuto diplomovou práci vˇenoval svému dˇedeˇckovi ing. Miloslavu Hudíkovi Csc., který se jejího dokonˇcení bohužel nedoˇckal.

iii

iv

Prohlášení Prohlašuji, že jsem svou diplomovou práci vypracoval samostatnˇe a použil jsem pouze podklady uvedené v pˇriloženém seznamu. Nemám závažný d˚uvod proti užití tohoto školního díla ve smyslu §60 Zákona cˇ . 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zmˇenˇe nˇekterých zákon˚u (autorský zákon).

V Praze dne 19.1. 2007

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

v

vi

Abstrakt Obsahem mé práce je rozšíˇrením simulátoru neuronových sítí Simonne o vzdálený pˇrístup a to více uživatel˚um zároveˇn pomocí nˇekolika odlišných služeb a o základní správu jejich kont. Komunikace smˇerem k uživateli je ˇrešena pomocí protokolu Jabber (Instant messaging) a mailového spojení s možností jednoduchého rozšíˇrení o další služby. Pˇri implementaci byl brán ohled na jednoduchost komunikace s uživatelem a na možnost použití simulátoru ve výuce.

Abstract The topics of my thesis is to implement new features of neural network simulator Simonne and to extend it by a remote control mechanism. The access of multiple users using several different services and basic administration of their accounts has been included to the extension as well. A communication in the direction from users towards system has been solved by IM protocol-Jabber and an email connection which is easily extensible by other services. During the implementation, I focused on easy-to-use communication of the simulator with users and on the possible use of the system for future educative purposes.

vii

viii

Obsah Seznam obrázku˚

xi

1 Úvod 1.1 Pˇrehled tématu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 3

I Teoretická cˇ ást

4

2 Teoretická cˇ ást 2.1 Klient - Server . . . . . . . . . . . . . . . . . . . . . . 2.2 Tenký a tlustý klient . . . . . . . . . . . . . . . . . . . 2.2.1 Aplikaˇcní program . . . . . . . . . . . . . . . 2.2.2 Softwarový tenký klient . . . . . . . . . . . . 2.2.3 Výhody . . . . . . . . . . . . . . . . . . . . . 2.2.3.1 Výhody tenkého klienta . . . . . . . 2.2.3.2 Výhody tlustého klienta . . . . . . . 2.3 Webová aplikace . . . . . . . . . . . . . . . . . . . . 2.3.1 Technické aspekty . . . . . . . . . . . . . . . 2.4 Komunikaˇcní protokoly a služby . . . . . . . . . . . . 2.4.1 RMI . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Email . . . . . . . . . . . . . . . . . . . . . . 2.4.3 Instant messaging . . . . . . . . . . . . . . . . 2.4.3.1 ICQ/AIM . . . . . . . . . . . . . . 2.4.3.2 MSN Messenger . . . . . . . . . . . 2.4.3.3 Jabber . . . . . . . . . . . . . . . . 2.4.3.4 Google Talk . . . . . . . . . . . . . 2.4.4 Podrobnˇejší popis protokolu Jabber . . . . . . 2.4.4.1 Komunikace . . . . . . . . . . . . . 2.4.4.2 Jabber identification . . . . . . . . . 2.4.4.3 Resource . . . . . . . . . . . . . . . 2.4.4.4 Jabber-transport . . . . . . . . . . . 2.4.4.5 Šifrování . . . . . . . . . . . . . . . 2.5 Rozbor simulaˇcních systém˚u se vzdálenýmm pˇrístupem 2.5.1 Mathematica . . . . . . . . . . . . . . . . . . 2.5.2 MATLAB . . . . . . . . . . . . . . . . . . . . 2.6 Design patterns . . . . . . . . . . . . . . . . . . . . . 2.6.1 Observer Pattern . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

II Praktická cˇ ást

5 5 5 6 6 6 6 7 7 8 8 8 9 10 10 11 11 11 12 12 13 13 13 13 14 14 15 16 17

18

3 Praktická cˇ ást 3.1 Prvotní návrh . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Výsledný návrh . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Komunikace mezi Simonne a uživatelem . . . . . . 3.2.1.1 Rozbor komunikaˇcních protokol˚u a služeb 3.2.1.2 Komunikace s uživateli pomocí 1. úˇctu . . ix

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

19 19 21 21 21 22

3.2.2 3.2.3

3.2.1.3 Implementace komunikaˇcní cˇ ásti serveru do p˚uvodního kódu 3.2.1.4 Komunikace s uživateli pomocí více úˇct˚u . . . . . . . . . . . Použití observer pattern a její rozšíˇrení . . . . . . . . . . . . . . . . . Komponenty a jejich komunikace . . . . . . . . . . . . . . . . . . . . 3.2.3.1 MessageEvent . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3.2 Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3.3 MessageType . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3.4 Komponenta . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.3.5 Komponenta SimServer . . . . . . . . . . . . . . . . . . . . 3.2.3.6 Komponenta User . . . . . . . . . . . . . . . . . . . . . . . 3.2.3.7 Komponenta SimServerManager . . . . . . . . . . . . . . . 3.2.3.8 Komponenta UserManager . . . . . . . . . . . . . . . . . . 3.2.3.9 Komponenta Connection . . . . . . . . . . . . . . . . . . . 3.2.3.10 Komponenta ConnectionController . . . . . . . . . . . . . .

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

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

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

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

24 26 27 27 28 28 29 29 30 30 31 31 31 32

III Závˇer

33

4 Závˇer 4.1 Shrnutí práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Budoucnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34 34 35

IV Pˇrílohy

36

A Instalaˇcní pˇríruˇcka

37

B Obsah CD

38

C Seznam literatury

39

x

Seznam obrázku˚ 1.1

Komunikace uživatele se Simonne. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 2.14

Rozdíly mezi klienty. . . . . . . . . . . . . . . . . . . . . . . . . . . . Schéma webové aplikace. . . . . . . . . . . . . . . . . . . . . . . . . . Schéma RMI spojení. . . . . . . . . . . . . . . . . . . . . . . . . . . . Loga IM klient˚u spoleˇcnosti AOL . . . . . . . . . . . . . . . . . . . . Windows Messenger logo. . . . . . . . . . . . . . . . . . . . . . . . . Jabber logo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Google Talk logo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schéma komunikace mezi klienty služby Jabber. . . . . . . . . . . . . . Jabber identification (JID). . . . . . . . . . . . . . . . . . . . . . . . . Jabber transport. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Porovnání Mathematica a webMathematica . . . . . . . . . . . . . . . Komunikace mezi webovým prohlížeˇcem a serverem webMathematica. MATLAB pro internetové prostˇredí. . . . . . . . . . . . . . . . . . . . Observer pattern. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13

P˚uvodní struktura Simonne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Komunikace prostˇrednictvím RMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Komunikace mezi simulátory bˇežících na serveru a klienty. . . . . . . . . . . . . . . . Detailní komunikace mezi simulátorem a klientem. . . . . . . . . . . . . . . . . . . . Komunikace s uživateli pomocí jednoho úˇctu. . . . . . . . . . . . . . . . . . . . . . . Schéma pˇríchozí zprávy pˇri použití jednoho úˇctu. . . . . . . . . . . . . . . . . . . . . Komunikace s uživateli po zaˇclenˇení implementace komunikaˇcního serveru do Simonne. Ukázka komunikace mezi uživatelem s cílovou komponentou. . . . . . . . . . . . . . Schéma pˇríchozí zprávy pˇri použití více úˇct˚u. . . . . . . . . . . . . . . . . . . . . . . Komunikace s uživateli pomocí více úˇct˚u. . . . . . . . . . . . . . . . . . . . . . . . . Schéma posílání a pˇreposílání zpráv. . . . . . . . . . . . . . . . . . . . . . . . . . . . Schéma registrace jednotlivých typ˚u pozorovatel˚u (Observer). . . . . . . . . . . . . . Propojení mezi uživateli a jednotlivými komponentami. . . . . . . . . . . . . . . . . .

19 19 20 20 22 23 24 24 25 26 28 29 32

4.1

Komunikace uživatele pomocí Instant messaging klienta se Simonne. . . . . . . . . . .

34

xi

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

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

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

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

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

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

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

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

2 6 7 9 10 11 11 12 12 13 14 15 15 16 17

xii

1

Pˇrehled diplomové práce Tato práce je rozdˇelena do cˇ tyˇr cˇ ástí - teoretické, praktické, závˇeru a pˇríloh: • Kapitola 1 obsahuje úvod do tématu, základní seznámení s ˇrešeným problémem a cíle této diplomové práce • Kapitola 2 se vˇenuje teoretickému rozboru práce. Obsahuje pˇrehled možných komunikaˇcních protokol˚u a služeb, které mohou být použity pˇri ˇreení vytyˇcených cíl˚u. • Kapitola 3 se zabývá konkétními návrhy ˇrešení. Popisuje jejich výhody a zápory. • Kapitola 4 obsahuje celkové shrnutí práce. • Pˇríloha A je instalaˇcní pˇríruˇcka. • Pˇríloha B je obsah pˇriloženého CD. • Pˇríloha C je seznam použité literatury.

KAPITOLA 1. ÚVOD

2

1 Úvod 1.1 Pˇrehled tématu Neuronové sítˇe tvoˇrí významnou souˇcást oboru umˇelé inteligence. Matematické modely neuronových sítí více cˇ i ménˇe napodobují nebo jsou alespoˇn inspirovány pozorováním kognitivních soustav v živých organismech vˇcetnˇe cˇ lovˇeka. Cílem oboru je vytvoˇrit software pˇrípadnˇe hardware nebo obecnˇeji matematický model, který by svým chováním pˇripomínal chování srovnatelné s inteligentními bytostmi. Tato snaha naráží na složitost živýchch vzor˚u, ale zároveˇn jsou nám živé vzory d˚ukazem, že ˇrešení existuje. Simulátory neuronových sítí jsou programy, které mají na vstupu popis neuronoveé sítˇe a vstupních parametr˚u (nˇekdy závislých na cˇ ase) pro vstupní neurony sítˇe. Jejich výstupem jsou hodnoty excitace (obecnˇeji cˇ íslo) výstupních neuron˚u (též pˇrípadnˇe v závislosti na cˇ ase) a pro úˇcely zkoumání i libovolnˇe další pr˚ubˇehy z vnitˇrku sítˇe. SiMoNNe [3] je univerzální simulátor pro modulární neuronové sítˇe. Vstup je popsán pomocí programovacího jazyka specializovaného pro simulaci modulárních sítˇe (též nazývaný SiMoNNe). Výstup je v textové formˇe. Textový jazyk však m˚uže být nejen pˇrímým komunikaˇcním prostˇredkem s uživatelem, ale m˚uže sloužit pro pˇripojení ke grafickému rozhraní.

Obrázek 1.1: Komunikace uživatele se Simonne.

KAPITOLA 1. ÚVOD

3

1.2 Cíle Hlavním cílem této práce je rozšíˇrit simulátor neuronových sítí Simonne o vzdálenou komunikaci s uživatelem pˇres internet nebo pˇres lokální sít’ a pˇritom zohlednit možnost využití simulátoru ve výuce. Zvláštní ohled je kladen na minimalizaci nárok˚u na uživatele, které jsou nutné pro základní práci se simulátorem Simonne. Rozšíˇrení se bude týkat následujících cˇ ástí: • Bˇeh více simulátor˚u zároveˇn. • Souˇcasný pˇrístup více uživatel˚u k jednotlivým simulátor˚um. • Intuitivnost a jednoduchost komunikace s uživatelem. • Návrh systému jednoduše rozšíˇritelného o další cˇ ásti, pˇríkazy, pˇrípadnˇe o další komunikaˇcní služby.

ˇ Cást I

Teoretická cˇ ást

4

ˇ KAPITOLA 2. TEORETICKÁ CÁST

5

2 Teoretická cˇ ást V této kapitole budo pˇriblíženy možnosti vzdáleného komunikace, jednotlivých komunikaˇcních služeb a ˇrešený jiných simulaˇcních systém˚u. Na konci kapitoly jsou zmínˇeny design pattern, které jsou používány pˇri návrhu aplikace.

2.1 Klient - Server Klient – server je sít’ová architektura, která oddˇeluje klienta (ˇcasto je to aplikace, která používá grafické rozhraní) od serveru. Server pˇritom nabízí služby, které jsou na nˇem pˇrítomny a své výpoˇcetní prostˇredky. Klient naopak obsahuje interakci s klientem. Každá instance klientského programu m˚uže zaslat žádost na server [17]. Charakteristika serveru: • vyšší nároky na hardware • pasivní (slave) • cˇ eká na žádosti • po obdržení žádosti ji zpracuje a odešle zpˇet odpovˇed’ Charakteristika klienta: • nízké nároky na hardware • aktivní (master) • posílá požadavky • cˇ eká na odpovˇedi, které zasílá server

2.2 Tenký a tlustý klient V navrhování aplikace typu klient-server, musí být rozhodnuto, která cˇ ást aplikace má byt provedena na serveru a která cˇ ást u klienta. Toto rozhodnutí m˚uže kriticky ovlivnit ekonomické náklady na server a na klienta, robustnost a bezpeˇcnost aplikace jako celku a flexibilitu designu k dalším modifikacím nebo portování. Hlavní otázka návrhu aplikace je, jak specifický má být klientský software. Použití standardních klientských program˚u jako napˇríklad webový prohlížeˇc nebo X11 m˚uže uspoˇrit vývojáˇru˚ m náklady a cˇ as, nebot’ nejsou nuceni vyvíjet specializovaného klienta. Musí ale pˇrijmout limitace standardizovaného klienta. V závislosti na výsledku tohoto rozhodnutí m˚užeme ˇríci, že používáme bud’ tenkého nebo tlustého klienta (nebo kombinaci obou). Charakteristiky: • Tlustý klient tak klade vˇetší hardwarové i softwarové nároky na klienta, tenký naopak na stranu serveru a na komunikaci. Tlustý klient má vˇetšinou nižší objem pˇrenesených dat než tenký klient. Rozdˇelení klientských aplikací na tenkého a tlustého klienta není striktní, ˇrada aplikací je na pomezí tˇechto skupin.


6

• Tenký klient je oznaˇcení takových aplikací, u nichž se na stranˇe klienta vykonává minimum aplikaˇcní logiky a vˇetšina se vykonávána na stranˇe serveru, který je pro tyto operace dostateˇcnˇe hardwarovˇe vybaven. • Ultra tenký klient má za úkol pouze zobrazovat data, odpadá jakákoliv komunikace s klientem. Má tedy ještˇe menší hardwarové nároky než tenký klient.

Obrázek 2.1: Rozdíly mezi klienty.

2.2.1

Aplikaˇcní program

Tenký klient jako aplikaˇcní program komunikuje s aplikaˇcním serverem, který typicky bˇeží na vzdáleném poˇcítaˇci. Komunikující klient a sever jsou spolu propojeni lokální sítí nebo pˇres internet. Tenký klient provádí vˇetšinu výpoˇct˚u na centrálním serveru s jen malou výpoˇcetní podporou na stranˇe klienta. Jednou z dalších možností odlišení tenkého od tlustého aplikaˇcního programu je podle toho, zda použití aplikaˇcního programu na stranˇe uživatele vyžaduje instalaci dalšího software. Toto rozdˇelení je diskutabilní. Napˇríklad webovový prohlížeˇc, který je cˇ ástí klientské platformy, nemusí být pˇrítomen na všech klientských poˇcítaˇcích, pˇrípadnˇe m˚uže vyžadovat doinstalování dalších cˇ ástí (plugins/addons). 2.2.2

Softwarový tenký klient

Vˇetšina tenkých klient˚u je nicménˇe pouze softwarového typu a bˇeží na standardních poˇcítaˇcích PC. Typický pˇríklad softwarového klienta jsou free maily, které komunikují s uživatelem pomocí webového prohlížeˇce (email.seznam.cz nebo mail.google.com). Další pˇríklad je ambiciózní projekt YouOS (www.youos.com), který na klientské stranˇe vyžaduje pouze webový prohlížeˇc. 2.2.3 2.2.3.1

Výhody Výhody tenkého klienta

• Nižší IT administraˇcní náklady. Tencí klienti jsou spravováni témˇerˇ úplnˇe na serveru. Hardware má menší pravdˇepodobnost chyby a lokální prostˇredí je vysoce omezeno kv˚uli poskytování ochrany pˇred malware. • Jednodušší zabezpeˇcení. Tenký klient m˚uže být navrhnut tak, že žádná data nejsou ukládány na stranˇe klienta. Centralizovaná ochrana proti malware. • Nižší náklady na hardware. Hardware tenkých klient˚u je obecnˇe levnˇejší, protože neobsahuje disk, mají menší množství operaˇcní pamˇeti a ménˇe výkonný procesor. • Nižší spotˇreba energie.

ˇ KAPITOLA 2. TEORETICKÁ CÁST 2.2.3.2

7

Výhody tlustého klienta

• Nižší cˇ etnost požadavk˚u na sever. Server pro tlustého klienta nevyžaduje vysoký výkon tak jako pro tenkého klienta (protože tlustí klienti provedou vˇetšinu výpoˇctu nutného pro bˇeh aplikace). Toto má za následek prudké snížení náklad˚u na server. • Vyšší multimediální výkon. Tlustí klienti mají mnoho výhod v multimediálních aplikacích, které by musely intenzivnˇe komunikovat se serverem. Napˇríklad tlustí klienti jsou velmi dobˇre vybaveni pro 3D hry. • Vˇetší flexibilita. Tlustý klient je velmi výhodný pˇri použití osobní potˇrebu.

2.3 Webová aplikace

Obrázek 2.2: Schéma webové aplikace.

Webová aplikace v softwarovém inženýrství je aplikace poskytovaná uživatel˚um z webového serveru pˇres poˇcítaˇcovou sít’ Internet, nebo její vnitropodnikovou obdobu (intranet). Webové aplikace jsou populární pˇredevším pro všudypˇrítomnost webového prohlížeˇce jako klienta. Ten se pak nazývá tenkým klientem, nebot’ sám o sobˇe logiku aplikace nezná. Schopnost aktualizovat a spravovat webové aplikace bez nutnosti šíˇrit a instalovat software na potenciálnˇe tisíce uživatelských poˇcítaˇcu˚ je hlavním d˚uvodem jejich oblíbenosti. Webové aplikace jsou používány pro implementaci mnoha podnikových i jiných informaˇcních systém˚u, ale i freemail˚u, internetových obchod˚u, online aukcí, diskusních fór, weblog˚u. V dˇrívˇejších typech aplikací typu klient-server mˇela každá aplikace sv˚uj vlastní klientský program, který sloužil jako její uživatelské rozhraní a musel být instalován na osobním poˇcítaˇci každého uživatele. Aktualizace serverové cˇ ásti typicky vyžadovala i aktualizaci klientských program˚u na každé pracovní stanici, což zvyšovalo náklady na podporu a snižovalo efektivnost zamˇestnanc˚u.


8

Oproti tomu webové aplikace generují dynamicky sérii webových stránek ve standardním formátu HTML/XHTML, který je podporován bˇežnými prohlížeˇci. Obecnˇe je každá jednotlivá webová stránka dodána prohlížeˇci jako statický dokument, ale sled takových stránek m˚uže vyvolat pocit interaktivity, napˇr. díky reakci na vstup uživatele do formuláˇrových prvk˚u vložených do kódu stránky. Pro pˇridání dynamických prvk˚u do uživatelského rozhraní se používá skriptovací jazyk JavaScript. Webový prohlížeˇc v pr˚ubˇehu bˇehu aplikace interpretuje a zobrazuje stránky a funguje jako univerzální klient pro libovolnou webovou aplikaci. 2.3.1

Technické aspekty

Podstatnou výhodou vývoje webových aplikací stavˇejících na standardních funkcích prohlížeˇce je jejich schopnost pracovat podle urˇcení bez ohledu na operaˇcní systém cˇ i jeho verzi instalovanou na daném klientském poˇcítaˇci. Místo psaní variant aplikace pro Windows, Linux, Mac OS X a další operaˇcní systémy staˇcí teoreticky aplikaci napsat jednou a nabídnout témˇeˇr kdekoliv. V praxi ale nekonzistentní implementace HTML, CSS, DOM a další specifikace jednotlivých prohlížeˇcu˚ zp˚usobují problémy. Navíc mají uživatelé možnost nastavit zp˚usob zobrazení ve svém prohlížeˇci (napˇr. zvolit jiný ˇrez cˇ i velikost písma, barvy cˇ i vypnout podporu skriptování), což m˚uže rušit jednotný vzhled aplikace. Dalším zp˚usobem, avšak ménˇe cˇ astým, je použití Macromedia Flash nebo javových applet˚u pro cˇ ást nebo celé uživatelské rozhraní. Ponˇevadž vˇetšina webových prohlížeˇcu˚ tyto technologie podporuje (obvykle formou zásuvných modul˚u), aplikace založené na Flashi cˇ i Javˇe mohou být v podstatˇe vyvíjeny a nasazovány všude stejnˇe snadno. Pˇrestože vývojáˇru˚ m poskytují vˇetší kontrolu nad uživatelským rozhraním a obcházejí ˇradu problém˚u s nastavením prohlížeˇcu˚ , mohou rozdílnosti mezi jednotlivými implementacemi Flashe cˇ i Javy zp˚usobit jiné komplikace. Pro podobnost jejich architektury s klasickými aplikacemi typu klient-server s jakýmsi tenkým klientem existují pochybnosti, zda systémy tohoto typu v˚ubec webovými aplikacemi nazývat a zda nepoužít termín rich internet application. Zˇrejmou nevýhodou tohoto pˇrístupu je vysoká závislost na poskytovateli aplikace a dostateˇcnˇe dimenzované kapacitˇe pˇripojení k serveru poskytovatele. Pokud se poskytovatel rozhodne ukonˇcit poskytování této služby nebo ji pˇreruší z jiného d˚uvodu, nelze službu nadále používat, na rozdíl od lokálnˇe provozovaného software. Stejnˇe tak pokud dojde k pˇrerušení spojení se serverem poskytovatele, m˚uže být služba doˇcasnˇe nedostupná.

2.4 Komunikaˇcní protokoly a služby Komunikaˇcní protokol jsou soubory pravidel, která zajišt’ují vzájemnou komunikaci mezi sít’ovými uzly. Jednotlivé protokoly mají velmi odlišné vlastnosti. Zde se budeme zabývat pouze aplikaˇcními protokoly. 2.4.1

RMI

Remote Method Invocation (RMI) [16] je mechanismus volání vzdálených metod specifický pro Javu. RMI tedy nelze použít ke komunikaci objekt˚u napsaných v jiném jazyku než Java. RMI je jednoduchý protokol, jednodušší než než jiné protokoly jako napˇríklad CORBA. RMI umožˇnuje objekt˚um bˇežících na jedné Java Virtual Machine (JVM) vyvolávat objekty na jiné JVM. Pˇritom JVM m˚uže bˇežet na stejném nebo jiném poˇcítaˇci. Komunikace probíhá pomocí TCP/IP spojení. RMI používá model klient-server. Server obsahuje objekty, jehož metody jsou klientem volány. RMI je navrhnuto takovým zp˚usobem, že klientovo volání serverových metod se neodlišuje od volaní lokálních metod.


9

Pˇri vytváˇrení RMI aplikace musí jak klient tak i server obsahovat rozhraní. Toto rozhraní definuje metody, které m˚uže klient vzdálenˇe volat. O zabezpeˇcené spojení se stará security manager. Pr˚ubˇeh:

Obrázek 2.3: Schéma RMI spojení.

1. Server zaregistruje Remote Object v RMI-Registry pod jednoznaˇcným jménem. 2. Klient hledá v RMI-Registry toto jméno a obdrží referenci na objekt, který odpovídá svým Remote Interface. 3. Klient zavolá metodu pomocí reference na objekt (to, že tato metoda existuje je garantováno Remote Interface). 4. Server vrátí Klientovi návratové hodnoty tohoto volání nebo Klient obdrží chybové hlášení (napˇríklad pˇri chybˇe spojení). 2.4.2

Email

Je to obdoba klasického poštovního systému se všemi výhodami a nevýhodami, které pˇrináší elektronické zpracovávání a pˇrenos dat. Základní vlastnosti elektronické pošty pro poˇcítaˇce pˇripojené do pˇríslušné sítˇe jsou následující: lze posílat libovolné soubory jednomu nebo více uživatel˚um, kteˇrí mají svou elektronickou adresu, lze používat poštovní schránky ( viz mailbox), do nichž systém automaticky ukládá došlou poštu v poˇradí, v nˇemž pˇrichází, je možné obdržené soubory prohlížet, editovat, posílat je dále atd. Kromˇe bˇežných text˚u lze elektronickou poštou posílat i soubory se zvukovými a obrazovými informacemi apod. Pro provoz elektronické pošty jsou tˇreba alespoˇn dva poˇcítaˇce (stanice), napojené do sítˇe, a pˇríslušné programové vybavení [7]. Za tvorbu a správné doruˇcení elektronické zprávy jsou zodpovˇedné dva typy program˚u. Prvnímu programu se rˇíká Mail User Agent (MUA). Je to program typu klient, který bˇeží na vašem poˇcítaˇci. Má na starosti pˇredevším zobrazování došlých zpráv a poskytnutí veškerého komfortu pro napsání nové zprávy. Navíc je ještˇe povinen zajistit pˇredání novˇe zapsané zprávy poštovnímu serveru. Druhému programu se rˇíká Mail Transport Agent (MTA). Tento program bˇeží na poštovním serveru a má za úkol ( za pomoci svých koleg˚u na dalších serverech) postarat se o správné doruˇcení zprávy do poštovní schránky adresáta. Poštovní servery mezi sebou komunikují pomocí protokolu SMTP.


10 2.4.3

Instant messaging

Instant messaging [11] je internetová služba, umožˇnující svým uživatel˚um sledovat, kteˇrí jejich pˇrátelé jsou právˇe pˇripojeni, a dle potˇreby jim posílat zprávy, chatovat, pˇreposílat soubory mezi uživateli a i jinak komunikovat. Hlavní výhodou oproti používání napˇr. emailu spoˇcívá v principu odesílání a pˇrijímání zpráv v reálném cˇ ase. Jinými slovy zpráva je doruˇcena ve velmi krátké dobˇe od odeslání (vˇetšinou v rámci stovek milisekund). Komunikace je zprostˇredkována pomocí poˇcítaˇce pˇripojeného k síti jako je napˇríklad internet. Instant messaging zrychluje komunikaci a umožˇnuje snadnou spolupráci mezi více lidmi. Narozdíl od emailu konverzace probíhá realtime a druhá strana ví, zda je úˇcastník k dispozici cˇ i nikoliv. Každý úˇcastník má k dispozici “seznam kontakt˚u“ (buddy list, roster), do kterého si m˚uže pˇridávat další uživatele stejné služby. Vˇetšina IM systém˚u umožˇnuje nastavit away message (online, offline, pryˇc, nerušit, . . . ), tedy zprávu podle které lze zjistit, zda je uživatel pˇrítomen pˇrímo u svého poˇcítaˇce a pˇrípadnˇe ochoten komunikovat. Na druhou stranu uživatele nikdo nenutí, aby na zprávy odpovídali ihned. Tímto zp˚usobem se IM komunikace stává ménˇe vyrušující než tˇreba telefon a to je cˇ ásteˇcný d˚uvod, proˇc je tento zp˚usob komunikace stále více oblíben v obchodním prostˇredí. Instant messaging je ideální pro rychlou výmˇenu internetových adres, kus˚u zdrojového kódu a dalších vˇecí, které se napˇr. v telefonní komunikaci špatnˇe pˇrenášejí. Instant messaging nemusí nastávat jen mezi dvˇema komunikujícími, chat room m˚uže být souˇcasnˇe pˇrístupná i velkému množství simultánnˇe komunikujících. [15] 2.4.3.1

ICQ/AIM

(a) ICQ logo

(b) AIM logo

Obrázek 2.4: Loga IM klient˚u spoleˇcnosti AOL

• Dvˇe nejpoužívanˇejších IM služby [6] [9] • Obˇe používají protokol OSCAR, jehož patent vlastní spoleˇcnost AOL • Komunikaˇcní servery ve vlastnictví spoleˇcnosti AOL • Uzavˇrený – informace o protokolu jsou získávány pouze reverzním inženýrstvím a rozborem paket˚u zachycených sniffer programy (tcpdump, Ethereal, Wireshark); problémy se zmˇenou komunikaˇcního protokolu; pokud dojde ke zmˇenˇe, trvá urˇcitý cˇ as, než se projeví zmˇena v knihovnách pro tento protokol • Problémy s licencí – jakákoliv zpráva, která je poslána službou ICQ patˇrí spoleˇcnosti AOL [10] [1] • Jedinná Java implementace protokolu OSCAR (služba ICQ využívá tento prokol) – velmi složitá (pˇres 900 tˇríd)


11

Obrázek 2.5: Windows Messenger logo.

2.4.3.2

MSN Messenger

• Proprietární IM podobnˇe jako ICQ vyvíjený bˇehem let 1999-2006 spoleˇcností Microsoft [14]. Microsoft zveˇrejnil druhou verzi protokolu (MSNP2) v roce 1999, ale nikdy nezveˇrejnil informace o dalších verzích (konkrétnˇe 8-14 a právˇe aktuální verzi 15 – starší verze nejsou pro komunikaci podporovány). Alternativní knihovny jsou programovány podle informací získaných reverzním inženýrstvím a rozborem paket˚u zachycených sniffer programy (tcpdump, Ethereal, Wireshark). • Protokol MSNP (Mobile Status Notification Protocol) komunikující pomocí TCP/IP spojení s .NET Messenger Service (služba je nabízena na messenger.hotmail.com na portu 1863) 2.4.3.3

Jabber

Obrázek 2.6: Jabber logo.

• Jabber [12] [13] otevˇrené standarty: IETF (Internet Engineering Task Force) normalizovala v ˇríjnu 2004 XML streamové jádro Jabber protokolu jako schválenou službu pro Instant messaging pod jménem XMPP. XMPP specifikace byla publikována jako RFC 3920 a RFC 3921. Nejsou vyžadovány žádné poplatky za implementaci podpory tˇechto specifikací a jejich vývoj není vázán s jediným výrobcem. • Decentralizace: Architura sítˇe Jabber je podobná emailu; každý m˚uže provozovat vlastní Jabber server a neexistuje centrální master server. • Historie: Protokol Jabber se využívá od roku 1998. Mnohonásobné implementace standard˚u Jabber existují jak pro klienty, servery, komponenty, tak i pro knihovny s podporou velkých spoleˇcností jako je Sun Microsystems nebo Google. • Pružnost: Speciální funkˇcnost m˚uže být zabudována nad jádrem Jabber protokolu; pro udržování vzájemné kompability, r˚uzná rozšíˇrení jsou ˇrízena Jabber Software Foundation. • Bezpeˇcnost: Jabber servery mohou být izolovány od veˇrejné Jabber sítˇe (napˇríklad pˇri použití v podnikovém intranetu). Do specifikace XMPP byla zabudováno také robustní zabezpeˇcení – SASL a TLS. 2.4.3.4

Google Talk

• Souˇcást Jabber/XMPP sítˇe - bezproblémová komunikace mezi uživateli, možnost použít jiného klienta [8]


12

Obrázek 2.7: Google Talk logo.

• Spoleˇcnost Google uvedla koncem roku 2005 nový projekt Google Talk. Tato služba pro Instant Messaging využívá protokolu XMPP, což je oficiální název pro základ Jabber protokolu. Dále pˇridala možnost hlasové komunikace, na jejíž specifikaci spolupracuje s Jabber Software Foundation. • Propojení s emailovou schránkou Gmail • K dispozici také webové rozhraní • Pˇrenos hlasu 2.4.4 2.4.4.1

Podrobnˇejší popis protokolu Jabber Komunikace

Sít’ Jabberu pracuje na stranˇe serveru (klienti nekomunikují pˇrímo), ale je decentralizována. To znamená, že neexistuje žádný centrální server, který by spojoval uživatele, jako je tomu napˇríklad u ICQ. Výhodou tohoto ˇrešení je, že si každý m˚uže zˇrídit sv˚uj vlastní server. Ovšem i poté bude moci komunikovat s uživateli na jiných serverech. Samozˇrejmˇe existuje spousta server˚u, na kterých se lze zdarma zegistrovat bez potˇreby tvorby serveru vlastního. Uživatel je identifikován uživatelským jménem a názvem serveru. Tyto dvˇe hodnoty jsou oddˇeleny znakem @. Tedy napˇríklad [email protected]. Tento ˇretˇezec se nazývá Jabber ID nebo také JID. Co se dˇeje pˇri komunikaci mezi dvˇema servery si ukážeme na názorném pˇríkladu. Uživatelka [email protected] si chce povídat s uživatelem [email protected]. J˚ulie má úˇcet na serveru Kapuletova.cz a Romeo na Montek.com. Když J˚ulie napíše zprávu a pošle ji Romeovi stane se nˇekolik akcí: 1. Jabber klient Julie pošle její zprávu serveru Kapuletova.cz • Pokud je Montek.com blokován, zpráva je smazána 2. Server Kapuletova.cz otevˇre spojení k serveru Montek.com 3. Server Montek.com doruˇcí zprávu Romeovi • Pokud je server Kapuletova.cz na Montek.com blokován, zpráva bude smazána • Pokud není Romeo právˇe pˇripojen, zpráva se uschová a bude doruˇcena pozdˇeji

Obrázek 2.8: Schéma komunikace mezi klienty služby Jabber.

ˇ KAPITOLA 2. TEORETICKÁ CÁST 2.4.4.2

13

Jabber identification

Jabber identification (krátce JID nebo Jabber-ID) umožˇnuje identifikaci jedné entity (myšleno jako reálný uživatel, bot, jabber-server, služba nebo kombinace pˇrechozích) v rámci Jabber sítˇe. Má formu [email protected]/home a pˇripomíná emailovou adresu.

Obrázek 2.9: Jabber identification (JID).

• První cˇ ást adresy je node (v pˇríkladu alice), který oznaˇcuje uživatelské jméno (username). To je volitelné, ale chybí jenom pˇri oznaˇcení server˚u nebo služeb. • Potom následuje doména oddˇelená od username pomocí znaku ’@’ (v pˇríkladu example.com). Ta urˇcuje server, na kterém je username registrováno. • Dalším nepovinným údajem je resource (v pˇríkladu home), které následuje po znaku ’/’. Tento údaj zadává uživatel libovolnˇe. 2.4.4.3

Resource

Resource je libovolnˇe volitelný ˇretˇezec znak˚u, který umožˇnuje zadat údaj, odkud je uživatel právˇe pˇrilogován (napˇríklad „doma“ nebo „práce“). S pomocí tohoto údaje m˚uže server rozhodovat, že uživatel se stejným úˇctem m˚uže být nalogován z více poˇcítaˇcu˚ . Pˇri pˇríchozí zprávˇe bude je rozhodnuto na základˇe priority, kterému klientu bude zaslána zpráva, pokud není pˇresnˇe zadán cíl pomocí ressource. Tato prioritní hodnota je nastavována klientem uživatele JID, kde vyšší cˇ ísla mají pˇrednost. Platný rozsah leží od -128 do 127. Záporná cˇ ísla mají speciální význam: klienti se zápornou prioritou nedostanou žádnou zprávu, pokud jim není pˇrímo explicitnˇe adresována pomocí ressource. Také uživatel konta se zdá být jako offline, pokud není žádný klient s pozitivní ressource online. Toto chování je užiteˇcné napˇríklad pro boty. 2.4.4.4

Jabber-transport

Jabber-transport (také jabber-agent nebo jabber gateway) je služba poskytovaná uvnitˇr sítˇe Jabber, která pˇredstavuje uživatele jiných IM systém˚u transparentnˇe jako Jabber uživatele. Tímto je možné využívat jiné služby jako AIM, ICQ, Y!M, Gadu-Gadu nebo IRC a jejich uživatele interagovat (podobnou možnost nabízí také MSN). Tato služba funguje jinak než multiprotokolový klienti. V pˇrípadˇe Jabberu se nevytváˇrí spojení tím, že na stranˇe klienta jsou podporovány pˇríslušné protokoly. Místo toho je propojení do cizích sítí umožnˇeno na stranˇe serveru. Server tedy „pˇrekládá“ zprávy mezi sítˇemi bez toho, aby se oba uživatelé r˚uzných komunikujících sítí museli pˇrijímat zvláštní opatˇrení. 2.4.4.5

Šifrování

Šifrování pˇri použití Jaberru se nenavazuje spojení mezi klienty nikdy pˇrímo, ale vždy pomocí minimálnˇe jednoho Jabber-serveru. Pokud jsou oba klienti pˇrihlášeni na dvou r˚uzných serverech, probíhá pˇrenos dat od prvního klienta k prvnímu serveru, od toho k druhému serveru a odtud k cílovému klientu. Protože Jabber je textový protokol, existuje zde možnost jednoduchého zachycení nekryptové komunikace. Z tohoto d˚uvodu nabízí Jabber následující bezpeˇcnostní funkce:


14

Obrázek 2.10: Jabber transport.

• SSL/TLS šifrování mezi klientem a serverem: SSL spojení k Jabber serveru je nabízeno na potu 5223. TLS spojení, pokud je na serveru podporováno, m˚uže být použito pomocí StartTLS také na standartním portu. Server také nabízí explicitnˇe port 5224 pro TLS. • Šifrování mezi severy: Mnohé servery nabízejí možnost šifrovánímezi sebou pomocí SSL. • Šifrování odesílatel-pˇríjemce (Peer-To-Peer Encryption): Protože klient neví nic o pˇrenosu zpráv mezi Jabber servery, vlastním zapezpeˇcení sever˚u nebo spojení klient-server na opaˇcné stranˇe, nelze se spolehnout na celkové zabezpeˇcení spojení mezi dvˇema klienty. Pro se m˚uže použít samotné šifrování mezi Jabber klienty: používá se bud’ OpenPGP a poslední dobou také Off-theRecord Messaging

2.5 Rozbor simulaˇcních systému˚ se vzdálenýmm pˇrístupem Vzdálený pˇrístup k simulaˇcním systém˚um je v drtivé vˇetšinˇe pˇredstavován webovou aplikací. Na stranˇe serveru je jádro simulaˇcního systému obaleno webovou technologií, které ji zpˇrístupˇnuje uživatel˚um komunikujících pomocí webového prohlížeˇce. 2.5.1

Mathematica

Propojuje aplikace Mathematica s webem vznikla webMathematica. Ta je založena na serverové technologii postavené na Java servletech. Stránky vytvoˇrené pomocí webMathematica mohou nabízet obsah v mnoha formátech, zahrnující HTML, r˚uzné typy obázk˚u, Mathematica poznámky, MathML a TeX. M˚uže spolupracovat pohodlnˇe s mnoha typy webových technologií podporovaných webovým prohlížeˇcem, jako napˇríklad HTML form, Java applety, JavaScript, Plugins a ActiveX. webMathematica také umí spolupracovat se serverovými technologiemi jako servlety a Java Server Pages. webMathematica poskytuje kolekci nástroj˚u, které umožˇnují umístit Mathematica pˇríkazy na HTML stránky; pokaždé, kdy je stránka požadována od webového serveru, tyto pˇríkazy jsou provedeny dotazem na aplikaci Mathematica. Komunikace klientem a serverem: 1. Webový prohlížeˇc posílá požadavek na webMathematica server. 2. webMathematica server si rezervuje Mathematica kernel (jádro) v kernel pool. 3. Mathematica kernel je nastaven se vstupními paramatery, provede kalkulace a vrací výsledky serveru. 4. webMathematica server vrací Mathematica kernel do kernel pool. 5. webMathematica server vrací výsledky webovému prohlížeˇci.


(a) Mathematica konzole

15

(b) stránka webMathematica

Obrázek 2.11: Porovnání Mathematica a webMathematica

Obrázek 2.12: Komunikace mezi webovým prohlížeˇcem a serverem webMathematica.

2.5.2

MATLAB

V nejnovˇejší verzi obsahuje MATLAB firmy MathWorks komponenty ’Builder’ pro jazyk Java, pˇrípadnˇe .NET. Tyto komponenty rozšiˇrují ’MATLAB Compiler’ o automatické generování Java (.NET) tˇríd z algoritm˚u MATLABu. Tyto tˇrídy mohou být spouštˇeny stejným zp˚usobem daný použitým jazykem nezávisle na prostˇredí MATLABu. Mohou být zaˇclenˇeny jak do klasických aplikací, tak i do aplikací webových. Hlavní pˇrednosti tohoto builderu jsou: • Pˇrevod algoritm˚u napsaných v MATLABu do Java tˇríd pomocí GUI nebo pˇríkazové ˇrádky • Podpora konverze mezi datovými typy v Javˇe a datovými poly v MATLABU


16

Obrázek 2.13: MATLAB pro internetové prostˇredí.

2.6 Design patterns Design patterns [2] jsou oznaˇcovány návrhové vzory a modely, které se používají pˇri opakovaném ˇrešení stejné situace, zejména pˇri potˇrebˇe rozvržení konstantních prvk˚u. Pˇredstavují tedy v daném kontextu optimální ˇrešení nejˇcastˇejších problém˚u. Návrhové vzory nejsou dokonˇceným návrhem, který m˚uže být pˇrímo transformován do kódu. Je to popis nebo šablona, jak vyˇrešit urˇcitý problém, který m˚uže být použit v rozdílných situacích. Objektovˇe orientované návrhové vzory ukazují typicky vztahy a interakci mezi objekty nebo tˇrídami bez specifikace jejich koneˇcné podoby, která je použita v aplikaci. Rozdˇelení návrhových vzor˚u je uspoˇrádáno do tˇrí základních skupin. • Creational Patterns rˇeší problémy související s vytváˇrením objekt˚u v systému. Snahou tˇechto návrhových vzor˚u je popsat postup výbˇeru tˇrídy nového objektu a zajištˇení správného poˇctu tˇechto objekt˚u. Vˇetšinou se jedná o dynamická rozhodnutí uˇcinˇená za bˇehu programu. • Structural Patterns pˇredstavují skupinu návrhových vzor˚u zamˇeˇrujících se na možnosti uspoˇrádání jednotlivých tˇríd nebo komponent v systému. Snahou je zpˇrehlednit systém a využít možností strukturalizace kódu. • Behavioral Patterns se zajímají o chování systému. Mohou být založeny na tˇrídách nebo objektech. U tˇríd využívají pˇri návrhu ˇrešení pˇredevším principu dˇediˇcnosti. V druhém pˇrístupu je ˇrešena spolupráce mezi objekty a skupinami objekt˚u, která zajišt’uje dosažení požadovaného výsledku.

ˇ KAPITOLA 2. TEORETICKÁ CÁST 2.6.1

17

Observer Pattern

Observer Pattern definuje závislosti jednoho objektu k více objekt˚um. Umožnˇení šíˇrení události, která nastala v jednom objektu, ke všem závislým objekt˚um. Observer je možné použít v situaci, kdy je definována závislost jednoho objektu na druhém. Závislost, ve smyslu tohoto návrhového vzoru, pˇredstavuje propagaci zmˇeny nezávislého objektu závislým objekt˚um (pozorovatel˚um). Nezávislý objekt musí informovat závislé objekty o událostech, které je mohou ovlivnit. Je nutné zajistit existenci zp˚usobu dynamické modifikace seznamu podˇrízených objekt˚u. Snahou je oddˇelit nezávislý nadˇrízený objekt od logiky informováni závislých objekt˚u, aby tyto mohly být informovány bez znalosti jejich vnitˇrní struktury.

Obrázek 2.14: Observer pattern.

ˇ Cást II

Praktická cˇ ást

18

ˇ KAPITOLA 3. PRAKTICKÁ CÁST

19

3 Praktická cˇ ást Dosavadní implementace simulátoru neronových sítí Simonne [3] [5] [4] se skládala z vlastního simulátoru a textové konzole. Vstup simulátor je popsán pomocí programovacího jazyka specializovaného pro simulaci modulárních sítˇe (též nazývaného Simonne). Výstup je v textové formˇe a je zobrazován v konzoli. Textový jazyk však m˚uže být využit pro pˇripojení grafického rozhraní.

Obrázek 3.1: P˚uvodní struktura Simonne.

Pro komunikaci se simulátorem na stranˇe serveru je využit pouze textový vstup a výstup ze simulátoru.

3.1 Prvotní návrh Pro komunikaci programu typu klient-server implementovaného v Javˇe pˇres internet nebo po lokální sítí je nejsch˚udnˇejší ˇrešení, které nabízí Java: RMI.

Obrázek 3.2: Komunikace prostˇrednictvím RMI.

Pro komunikaci mezi serverem a klientem, kdy obˇe cˇ ásti jsou psané v Javˇe, je nejelegantnˇejším ˇrešením zvolit RMI popsanou v sekci 2.4.1. Výhody vyžití RMI v implementaci jsou následující: • Jednoduchost. Použití RMI je intuitivní. Volání vzdálených metod se prakticky se neliší od volání lokálních metod. • Pˇrímá komunikace mezi objekty odbourává nutnost použití více vrstev v komunikaci, jako je pˇreklad volání jednotlivých metod na textové zprávy a jejich zpˇetné parsování. • RMI je souˇcástí Java Virtual Machine (JVM). Není tˇreba doinstalovávat další cˇ ásti pro bˇeh serveru. • Zabezpeˇcení komunikace mezi objekty je souˇcástí RMI. Bohužel u tohoto elegantního a jednoduchého ˇrešení vznikly vážné nedostatky, které si vynutily pˇrepracování celého návrhu: • Každý simulátor, který bude uživatel používat, bude mít vlastního klienta. Napˇríklad pro pˇet simulací bude nutno provozovat pˇet klient˚u.

20


Obrázek 3.3: Komunikace mezi simulátory bˇežících na serveru a klienty.

Obrázek 3.4: Detailní komunikace mezi simulátorem a klientem.

• Simulátor je pˇrímo závislý na klientovi. Simulátor není schopen výpoˇctu, pokud zároveˇn nebˇeží klient. Pokud napˇríklad se zhroutí poˇcítaˇc, na kterém klienti bˇeží, je zmaˇrena celá dosavadní simulace bez možnosti obnovy. • Velmi komplikované pˇridání dalších komunikaˇcních služeb, jako napˇríklad emailového transportu. Podrobnˇejší popis komplikací, které vznikly pˇridáním emailové komunikaˇcní vrstvy: • Jedná se o offline službu - server není schopen rozlišit, zda uživatel je pˇripojen. Zprávy pˇricházejí nezávisle na sobˇe. Vyvstává požadavek na provoz simulátor˚u nezávisle klientovi a na rozdˇelení na simulátory ve spojení s klientem a bez tohoto spojení. • Nutno zavést nové cˇ ásti, které se starají o simulátory nepˇripojené ke klientovi. Nutno ˇrešit problémy s managementem tˇechto simulátor˚u (napˇríklad jak dlouho m˚uže trvat výpoˇcet simulátoru, aniž by se musel uživatel pˇripojit).


21

• Problémy s kombinací obou pˇrístup˚u. • Je nutné zavést parser pˇríkaz˚u. Emailový transport pˇredává pouze textové zprávy. Mizí hlavní výhody RMI. • Výˇcet krok˚u pro zpracování pˇríchozího emailu a možné problémy: – Zpracuj pˇríkaz: parsuj, zjisti cílový simulátor. Nebyl simulátor mezitím zrušen? – Existuje takový simulátor, který bˇeží offline? – Existuje takový simulátor, který bˇeží online (pˇripojeno pˇres RMI)? Pokud ano, mám pˇredat pˇríkaz? Tyto problémy vedly k nutnosti pˇrepracování celého problému a kompletnˇe novému návrhu aplikace.

3.2 Výsledný návrh Problémy pˇredchozího návrhu si vyžádaly základní zmˇeny konceptu komunikace s uživatelem. Pˇri rozšíˇrení komunikaˇcních služeb pro spojení s uživatelem se vytratily výhody použití RMI - jeho jednoduchost. Rozšíˇrení o emailovou komunikaci (obecnˇe každou komunikace, která používá textové zprávy) si vynutilo doplnˇení programu o cˇ ásti jako napˇríklad parser. Zásadní zmˇenou oproti minulému ˇrešení je striktní oddˇelení vnˇejší komunikace s uživatelem a vytvoˇrení vnitˇrního jádra. Nová struktura pˇrinesla pˇredevším zjednodušení kódu a snadnˇejší množnost sledování událostí, které v programu nastaly. Napˇríklad odpadly problémy s komunikací pomocí nˇekolika služeb zároveˇn. Návrh vnitˇrního jádra vychází z design patterns (viz cˇ ást 2.6), konkrétnˇe z observer pattern (viz cˇ ást 2.6.1). Java sama nabízí pˇredpˇripravené objekty pro použití tohoto návrhového vzoru (konkrétnˇe interface Observer a tˇrídu Observable), ty ale nevyhovují potˇrebám pro svou jednoduchost (viz cˇ ást 3.2.2). Základním stavebním kamenem vitˇrního jádra je tzv. komponenta. Komponenta má nˇekolik klíˇcových vlastností. Pˇredevším m˚uže posílat zprávy libovolné jiné komponentˇe a naopak m˚uže zprávy od libovolné komponenty pˇrijímat a reagovat na nˇe. Každá komponenta má své unikátní jméno, je urˇcitého typu a je zaregistrována na jednoho konkrétního uživatele - vlastníka komponenty. Pokud chce s vlastníkem komunikovat, staˇcí vytvoˇrit zprávu, oznaˇcit ho jako adresáta a zprávu odeslat. Komponenty, které jsou nezbytnˇe nutné pro bˇeh celého systému (UserManager, ConncetionController, SimServerManager, Jabber a MailConnection) jsou registrovány na defaultního uživatele root. 3.2.1

Komunikace mezi Simonne a uživatelem

Zp˚usob komunikace Simonne s uživatelem se odvíjí nejen od použitých komunikaˇcních protokol˚u, ale také od poˇctu úˇct˚u, které bude Simonne využívá pro dorozumívání se s uživateli - zda Simonne pˇrijímá a zasílá zpravy uživatel˚um pomocí jen jednoho nebo vetšího množství kont pro každý protokol. 3.2.1.1

Rozbor komunikaˇcních protokolu˚ a služeb

Pro komunikaci mezi klientem a serverem je možné využít nˇekolika r˚uzných protokol˚u. Detailnˇejší popis jejich vlastností je v cˇ ást 2.4. • RMI (viz cˇ ást 2.4.1): Výhody a nevýhody použití RMI jsou popsány v cˇ ást 3.1


22

• Email (viz cˇ ást 2.4.2): Nejvˇetší výhodou pro použití emailu je jeho rozšíˇrenost. Mezi nevýhody pro použití emailu patˇrí jeho rychlost. Doba, než email doputuje ke svému adresátovi m˚uže dosáhnout až nˇekolika dní. Navíc pokud uživatel zašle nˇekolik email˚u (pˇríkaz˚u) zároveˇn, mohou dorazit v opaˇcném poˇradí, a to m˚uže mít pro simulaci fatální následky. • Instant Messaging (blíže popsáno v cˇ ást 2.4.3): Mezi hlavní pˇrednosti patˇrí komunikace v reálném cˇ ase. Pokud nelze zprávu doruˇcit (napˇríklad uživatel je offline), zprávy se bufferují na serveru použité služby. – ICQ, AIM, MSN Messenger: Použití jakéhokoliv z uzavˇrených služeb se vystavujeme problém˚um s komunikací pˇri zmˇenˇe použitého protokolu. Navíc výbˇer knihoven bývá drasticky omezen. – Jabber(blíže popsáno v cˇ ásti 2.4.3.3): Nespornou výhodou použití Jabberu je jeho otevˇrenost, výbˇer knihoven a možnost provozovat vlastní server. Unikátní vlastností je Jabber-Transport (viz cˇ ást 2.4.4), který umožˇnuje komunikaci Jabber-ICQ, Jabber-Email, pˇrípadnˇe jiné. 3.2.1.2

Komunikace s uživateli pomocí 1. úˇctu

Propojení Simonne smˇerem k uživateli probíhá u zvolené služby pomocí jednoho uživatelského konta, ke kterému se Simonne pˇripojuje a pˇres které komunikuje s uživateli. To ˇrešení pˇrináší pouze jedinou výhodu a spoustu komplikací: Nejvˇetší (prakticky jedinou) výhodou tohoto rˇešení je velmi jednoduché rozšíˇrení o další komunikaˇcní kanály k uživateli. Pro implementaci je dostaˇcující Java API této služby a jedno klientské konto pro danou službu. Toto konto je možno vytvoˇrit manuálnˇe (Simonne nevytváˇrí žádná nová konta).

Obrázek 3.5: Komunikace s uživateli pomocí jednoho úˇctu.

Usability • Uživatel je nucen se nauˇcit více pˇríkaz˚u pro interakci se systémem. Musí se nauˇcit jak pˇríkazy pro ovládání svého konta v systému, tak i ovládání vlastního simulátoru. V každém pˇríkazu musí uvádˇet jak cílovou komponentu, tak i pˇríkaz. Pokud se uživatel zmýlí a zadá správný pˇríkaz, ale zašle ho špatné komponentˇe (napˇríklad cílem bude jiný simulátor), m˚uže nastat fatální chyba a v nejhorším scénáˇri bude muset zaˇcít výpoˇcet znovu. • Pˇri obdržení zpráv od více simulátor˚u musí uživatel velmi peˇclivˇe rozlišovat mezi zprávami. Zprávy pˇricházejí z jediného konta a nedají se odlišit podle odesílatele zprávy. Rozlišovat se


23

nechá pouze podle obsahu. Pokud se jedná o výsledky simulace, budou si zprávy navzájem velmi podobné. • Pˇri procházení historie zpráv vzniká podobný problém jako pˇri obdržení zpráv od více simulátor˚u najednou. Pokud klientský program nepodporuje ruˇcní ˇrazení zpráv do jednotlivých složek (což vyžaduje uživatelovu aktivitu), veškeré zprávy budou v jednom adresáˇri a uživatel se bude s obtížemi orientovat, od jakého jakého simulátoru danou zprávu obdržel.

Obrázek 3.6: Schéma pˇríchozí zprávy pˇri použití jednoho úˇctu.

Zprávy od r˚uzných uživatel˚u se rozlišují pouze podle odesílatele zprávy. Podle obsahu každé zprávy musí systém být schopen rozlišit, pro kterou cˇ ást systému je daná zpráva urˇcena. Jediným zp˚usobem, jak to docílit je zavedení pˇríkazového jazyka, podle kterého se bude urˇcovat adresát zprávy. Vlastní implementace aplikace bude složitˇejší, nebot’ je nutno komunikující komponentu rozšíˇrit o následující cˇ ásti: • Komunikace: uživatel → Simonne – Nutnost komunikaˇcního jazyka – pˇri pˇríjmu se musí urˇcit cílová komponenta, které zpráva je urˇcena. Cíl zprávy se nedá urˇcit z pole adresát (napˇríklad mailová adresa adresáta). Tedy v tˇelo zprávy musí obsahovat pˇríkazy, podle kterých je urˇcena cílová komponenta. Toto má své nevýhody. Pˇri pˇridání jakékoliv další komponenty do systému, musí být upravena komponenta pro odesílání zpráv. – Parser pˇríkaz˚u – nutný implementovat pro získání informací z obdržené zprávy. Parser bude muset být implementován v systému na dvou místech: jak v cílové komponentˇe (vlastní parsování pˇríkazu pro komponentu – napˇríklad vytvoˇr simulátor), tak v komponentˇe pˇrijímající zprávy z od uživatele (komu je zpráva urˇcena – napˇríklad pro správu uživatelova konta). Pokud je v systému komponent pˇrijímajících zprávy více (emailové, jabber spojení), musí každá z nich obsahovat ten samý parser. – Testování, zda daná komponenta v˚ubec existuje – pˇri pˇrijmu zprávy komponenta pˇrijímající zprávu není schopna zjistit, zda komponenta existuje nebo byla zrušena (napˇríklad je zaslána zpráva pro simulátor, který byl zrušen). Musel by být zaveden index komponent. – Testování práv uživatele: pˇri pˇríjmu zprávy komponenta pˇrijímající zprávu není schopna zjistit, zda daný uživatel, který zprávu zaslal má práva na komunikaci s komponentou a tedy zda je pˇríkaz validní. • Komunikace: Simonne → uživatel – Není žádný problém pˇri odesílání zpráv. Zpráva se odešle pomocí uživatelského konta, které bylo pro Simonne zaregistrováno. – Pˇríjem zpráv uživatelovým klientem a jeho orientace v pˇrijatých zprávách je popsána v odstavci usability.


24 3.2.1.3

Implementace komunikaˇcní cˇ ásti serveru do puvodního ˚ kódu

Propojení Simonne smˇerem k uživateli probíhá u zvolené služby pomocí serveru, který je zaˇclenˇen do Simonne. Každá komponenta, která komunikuje s uživatelem, má na tomto serveru své vlastní konto, pˇres které odesílá zprávy uživateli. Toto ˇrešení pˇrináší nˇekteré zásadní výhody, ale i nˇekolik komplikací.

Obrázek 3.7: Komunikace s uživateli po zaˇclenˇení implementace komunikaˇcního serveru do Simonne.

Obrázek 3.8: Ukázka komunikace mezi uživatelem s cílovou komponentou.

Usability: • Oddˇelení komunikace nˇekolika komponent – uživatel nemusí v tˇele zprávy rozlišovat, komu zprávu zasílá. Cílová komponenta je pˇrímo urˇcena pˇríjemcem zprávy. Uživatel se nemusí uˇcit další pˇríkazy, jak by byl nucen v pˇredchozím návrhu. Tím se zjednodušuje práce a také se zmenšuje poˇcáteˇcní kvantum informací, které se musí uživatel pro základní práci se systémem Simonne nauˇcit. • Pˇri pˇríchodu více zpráv uživatel m˚uže bez problém˚u rozlišit, který simulátor (komponenta) zaslal danou zprávu. Vˇetšina klient˚u použitých služeb umí automaticky tˇrídit pˇrijaté zprávy (Instant messaging klienti tˇrídí automaticky, u emailového klienta se musí nastavit filtry pˇríchozí pošty). • Pˇri vytvoˇrení nové komponenty (napˇríklad nového simulátoru) vyšle zprávu uživateli, který ji vytvoˇril. Pro komunikaci s touto komponentou staˇcí uživateli zasílat zprávy nazpˇet (napˇríklad emailová funkce reply).


25

• Uživatel se mnohem jednodušeji orientuje v historii zpráv a nemˇelo by mu cˇ init potíže prohlížení starších zpráv od urˇcitého simulátoru (komponenty). Vlastní implementace - aplikaci je nutno komunikující komponentu rozšíˇrit o následující cˇ ásti: • nutnost zaˇclenit server dané služby do aplikace. Tento krok je velmi omezující a to hned z nˇekolika d˚uvod˚u: – Prvním omezením je omezení server˚u dané služby na ty, které jsou implementovány pomocí jazyka Java a je k dispozici volnˇe pˇrístupný kód – tedy implementace musí být open source. Toto kritérium je snižuje poˇcet možných server˚u (pˇrípadnˇe jeho API) na minimum. Napˇríklad email server existuje pouze jeden (projekt james, který vyvíjí Apache Foundation). Implementaci jakékoliv komunikaˇcní služby vyžaduje podrobné nastudování zdrojového kódu, nalezení rozhraní komunikace s jádrem serveru pˇríslušné služby a vytvoˇrení rozhraní pro automatickou komunikaci s urˇcitými cˇ ástmi Simonne. – Použitý server m˚uže mít další požadavky pro sv˚uj chod – napˇríklad instalaci SQL serveru, instalaci dalších systémových služeb, atd. – Ovládání Simonne se nepˇrimˇerˇenˇe zvýší. Management novˇe zaimplementovaného API si vyžádá nejen vyšší programátorské úsilí (musí být vytvoˇren kód, který ˇrídí serverovou cˇ ást dané služby), ale i vyšší úsilí správc˚u, kteˇrí budou Simonne provozovat. – Zvýšení poˇctu chyb v projektu Simonne - poˇcet chyb se zvýší o chyby, které dosud nebyly z API dané služby odstranˇeny. Simonne se stává nestabilnˇejší. – Pˇrechod na vyšší verzi API se stává problematickým – je nutno nastudovat rozdíly v použité a nové verzi serveru (API). – Zvýší se velikost projektu Simonne. – Výkon serveru (myšleno hardware) se sníží o systémové prostˇredky, které si vyžádá daná služba. Server služby a Simonne nelze od sebe oddˇelit (nelze službu pˇremísti na jiný server nebo využít již stávajícího serveru). • Komunikace: uživatel → Simonne

Obrázek 3.9: Schéma pˇríchozí zprávy pˇri použití více úˇct˚u.

– Odpadá nutnost komunikaˇcního jazyka a implementace parseru – cílová komponenta je jasnˇe urˇcena adresátem, kterému uživatel zprávu zasílá. Tento adresát se shoduje s komponentou (tedy username konta je shodný se jménem komponenty, který systém využívá). – Odpadá nutnost testování existence komponenty – každá komponenta má své konto. Pokud je komponenta zrušena, je také zrušeno její konto. Pokud uživatel zašle zprávu neexistující komponentˇe, tak dostane zprávu od severu, který tuto komunikaˇcní službu implementuje. Simonne se o toto nemusí nadále starat.


26

– Testování práv uživatele: k tomuto testování dochází již pˇri pˇríjmu. Odesílatel zprávy musí být totožný s vlastníkem komponenty (odkaz: viz implementace Jabber Connection). Tímto se dává d˚uvˇera v odesílatele zprávy a zabezpeˇcení jeho úˇctu. Pokud dojde k neshodˇe mezi odesílatelem a vlastníkem, je zpráva zahozena. • Komunikace: Simonne → uživatel – Není žádný problém pˇri odesílání zpráv. Pˇred odesláním zprávy uživateli se u komponenty, která zprávu odesílá zjistí její vlastník (uživatel, který ji vytvoˇril nebo na kterého je registrována) a následnˇe jeho konto, na které mu má být zpráva zaslána. Zpráva se odešle. (odkaz: viz implementace Jabber Connection a Observer pattern) – Pˇríjem zpráv uživatelovým klientem a jeho orientace v pˇrijatých zprávách je popsána v odstavci usability. 3.2.1.4

Komunikace s uživateli pomocí více úˇctu˚

Propojení Simonne smˇerem k uživateli probíhá u zvolené služby pomocí externí implementace serveru, který provozuje danou službu. Simonne na tomto vytvoˇrí automaticky vˇetší množství úˇct˚u. Každá komponenta, která komunikuje s uživatelem, má své vlastní konto, pˇres které odesílá zprávy uživateli. Toto ˇrešení si ponechává oproti minulému ˇrešení vˇetšinu jeho výhod, ale má i nˇekteré omezení.

Obrázek 3.10: Komunikace s uživateli pomocí více úˇct˚u.

Relativnˇe jednoduché rozšíˇrení o další komunikaˇcní služby. Pro danou službu musí pouze existovat klientské Java API a musí existovat zp˚usob, jak vzdálenˇe vytváˇret konta pro zasílání a pˇríjímání zpráv od uživatel˚u. Usability se oproti pˇredchozímu pˇrípadu nemˇení. Pro uživatele z˚ustává rozhraní naprosto stejné. Každá komponenta má své vlastní konto dané služby, pˇres které odesílá a pˇrijímá zprávy od uživatel˚u. Aplikaci je nutno komunikující komponentu rozšíˇrit o následující cˇ ásti Aplikaci je nutno komunikující komponentu rozšíˇrit o následující cˇ ásti: • Klientské Java API je ve vˇetšinˇe knihoven jednoduché a následná implementace klienta (použitého v Simonne pro stahování zpráv ze serveru) není složitá. • Pro komunikaci Simonne se serverem služby je nutné implementovat vlastnosti „pošli zprávu pomocí daného konta“, „stáhni zprávy z daného konta“, „vytvoˇr konto“ a „zruš konto“. Poslední


27

dvˇe jmenované vlastnosti jsou problematické. Vytvoˇrení nebo zrušení konta u mnohých server˚u nelze implementovat jako vzdálený pˇríkaz pomocí zpráv dané služby – server tuto schopnost nepodporuje. Pokud uživatel má možnost vytvoˇrit (zrušit) konto pomocí pˇríkazové ˇrádky, nechá se problém obejít spouštˇením pˇríkazu z pˇríkazové ˇrádky. Pokud server dané služby bˇežel na jiém poˇcítaˇci, je tˇreba implementovat vzdálený pˇrístup ke konzoly pomocí SSH. Výhody provozu vlastních server˚u • Hlavní výhodou je možnost provozováni server˚u na jiném stroji, kdy je možnost uspoˇrit výkon pro Simonne. • Není vždy nutností – vˇetšinou mohu využívat veˇrejné (jako napˇríklad servery Jabber) • Lepší zabezpeˇcení vlastního serveru a kontrola nad chodem daného serveru • Mohu provozovat lokálnˇe bez pˇrístupu na internet, pˇrípadnˇe do lokální sítˇe • Pro vˇetší poˇcet komunikujících komponent je lépe spravovat vlastní server, protože veˇrejné servery mohou mít restrikce, které pˇredem nejsou známy. Napˇríklad antispamovou ochranu, pokud Simonne využívá emailové komunikace. 3.2.2

Použití observer pattern a její rozšíˇrení

Systém posílání zpráv uvnitˇr systému je založen na observer pattern (viz. cˇ ást 2.6). Komponenta, která chce zprávy vysílat je ve skuteˇcnosti pozorovaný objekt (Subject). Komponenta, která chce zprávy pˇrijímat je pozorovatel (Observer). Tedy pozorovatel se zaregistruje u pozorovaného objektu (registerObserver(observer) viz. cˇ ást 2.6) a stane se pˇríjemcem všech jeho zpráv. Pokud pozorovaný objekt vyšle zprávu, obdrží ji všichni pozorovatelé. Pozorovatel m˚uže zprávu pˇreposílat vlastním pozorovatel˚um, kteˇrí se u nˇeho zaregistrovali. Protože všechny komponenty jsou navzájem provázány, vzniká problém nekontrolovatelného šíˇrení zprávy. Jestliže kterákoliv komponenta vyšle zprávu, obdrží ji všechny zbylé komponenty i v pˇrípadˇe, že jim není urˇcena. Pˇri vˇetším poˇctu komponent v systému dochází ke zbyteˇcnému plýtvání výpoˇcetních prostˇredk˚u. Proto bylo zavedeno nˇekolik typ˚u posluchaˇcu˚ : • all message observer: Tento posluchaˇc pˇrijímá všechny zprávy. Uplatní se tehdy, pokud je zaregistrován jen jeden posluchaˇc a není tˇreba rozlišovat typ zpráv. • type message observer: Pokud je zpráva urˇcitého typu, jsou informovány všechny komponenty, které si daný typ zprávy zaregistrovaly. Tím je napˇríklad docíleno, že všechny zprávy stejného typu postují systémem jedním smˇerem. • name message observer: Tento typ zprávy je urˇcen pro jednu konkrétní komponentu. Jestliže není žádná komponenta s tímto jménem zaregistrována, je zpráva podle svého typu pˇreposlána dál. Protože jednotlivé komponenty jsou pozorovateli a zároveˇn jsou pozorovány, mohlo by docházet k zacyklení zpráv. Aby se tomuto efektu zamezilo, pamatuje si každá zpráva, kterými objekty byla poslána. A pokud pozorovatel zprávu již jednou zpracoval, zpráva mu nebude zaslána. 3.2.3

Komponenty a jejich komunikace

Komponenty se podobají tˇrídám typu Listener, které jsou pevnou souˇcástí Javy a obsluhují události od kliknutí myši až po vykreslování oken.


28

Obrázek 3.11: Schéma posílání a pˇreposílání zpráv.

3.2.3.1

MessageEvent

Pokud se komponeta rozhodne zaslat jiné komponentˇe zprávu, vytvoˇrí událost MessageEvent. Souˇcástí MessageEvent jsou následující cˇ ásti: • Odkaz na komponentu, která vytvoˇrila tuto událost. • Vlastní zpráva. • Typ zprávy (MessageType) • Jméno cílové komponenty. 3.2.3.2

Message

Objekt Message je zpráva, kterou si komponenty mezi sebou posílají. Obsahuje pˇredevším: • typ zprávy (MessageType) • vlastní zpráva • cˇ as zaslání zprávy


29

Obrázek 3.12: Schéma registrace jednotlivých typ˚u pozorovatel˚u (Observer).

3.2.3.3

MessageType

MessageType je klíˇcovou souˇcástí každé zprávy. Podle hodnoty tohoto údaje je zpráva smˇeˇrována k cílové komponentˇe. Podle cílové komponenty má MessageType r˚uznou hodnotu: • TO-SEND: zpráva je urˇcena k odeslání • TO-SIMSERVER: zpráva je urˇcena komponentˇe typu SimServer • TO-SIMSERVER-MANAGER: zpráva je urˇcena komponentˇe typu SimServerManager • TO-USER: zpráva je urˇcena komponentˇe typu User • TO-USERS-MANAGER: zpráva je urˇcena komponentˇe typu UserManager • TO-CONNECTION: zpráva je urˇcena komponentˇe typu Connection • TO-CONNECTION-CONTROLLER: zpráva je urˇcena komponentˇe typu ConnectionController • TO-OTHER: zpráva je urˇcena neznámé komponentˇe (defaultní nastavní pro pˇrípad chyby a následného ladˇení) • TO-ALL: zpráva je urˇcena všem komponentám 3.2.3.4

Komponenta

Komponenty jsou objekty, které umí pˇrijímat a odesílat zprávy jak uživateli, tak i mezi sebou navzájem.


30

Odeslání zprávy jiné komponentˇe probíhá v nˇekolika krocích. Nejprve se vytvoˇrí vlastní zpráva (Message) a následnˇe údálost (MessageEvent). O té události jsou informovány všichni posluchaˇci (zaregistrované komponenty). 3.2.3.5

Komponenta SimServer

Hlavní funkce komponenty SimServer je zapouzdˇrení simulátoru. Zaˇcleˇnuje jeden simulátor do komunikaˇcní struktury komponent a je zodpovˇedný za pˇreposílání zpráv simulátorem a uživatelem. Všechny zprávy, které uživatel zašle komponentˇe SimServer, jsou pˇredány bez jakékoliv zmˇeny simulátoru. A naopak, zprávy, které odešle simulátor pomocí této komponenty, jsou zaslány uživateli. Tato vlastnost umožˇnuje komunikovat se simulátorem pˇrímo bez nutnosti používat speciální pˇríkazy pro rozlišení zpráv pro simulátor a pro komponentu SimServer. Pokud uživatel chce zmˇenit nˇekteré z nastavení této komponenty, musí využít pˇríkazy, které mu nabízí jeho uživatelské konto (viz cˇ ást 3.2.3.6). Uživatelské jméno, pod kterým se zobrazí v uživatelovˇe Jabber (pˇrípadnˇe emailovém) klientu je "jméno uživatele" + ´_´ + "sim" + "poˇradové cˇ íslo simulátoru", napˇríklad ’novaka1_sim3’. Pokud uživatel provozuje nˇekolik simulátor˚u zároveˇn, m˚uže ztratit pˇrehled o simulátorech a jejich úkolech. Uživateli je tedy umožnˇeno pˇridat komentáˇr ke každé komponentˇe SimServer (viz cˇ ást 3.2.3.6). Tato komponenta je zodpovˇedná za informování uživatele o stavu simulátoru. Protože uživatel by musel stále zasílat simulátoru dotazy na jeho aktuální stav, umožˇnuje tato komponenta automatické zasílání stavu simulátoru na konto uživatele. Uživatel m˚uže k Simonne pˇristupovat z r˚uzných klient˚u (myšleno z r˚uzných klient˚u stejné služby, napˇríklad z r˚uzných Jabber klient˚u). Nemá tedy na jiném klientovi pˇrístup k historii zpráv, které mu již tento simulátor zaslal. Napˇríklad nem˚uže posoudit vývoj simulace. Proto komponenta SimServer obsahuje historii pˇríkaz˚u, které odeslal nebo pˇrijal simulátor (pˇríkazy urˇcené pouze simulátoru, ne pˇríkazy urˇcené komponentˇe SimServer). 3.2.3.6

Komponenta User

Komponenta User pˇredstavuje pro uživatele hlavní bránu pro komunikaci se Simonne. Všechny pˇríkazy (mimo pˇríkaz˚u urˇcených konkrétnímu simulátoru) zasílá uživatel právˇe této komponentˇe. Pomocí této komponenty m˚uže uživatel provádˇet následující pˇríkazy: • createSimulator: tento pˇríkaz vytvoˇrí novou komponentu SimServer, která je napojena na novˇe vytvoˇrený simulátor. Komponenta SimServer je registrována na uživatele, který ji vytvoˇril. Ihned po své inicializaci zašle uživateli uvítací zprávu. Následnˇe se uživateli v jeho Jabber klientu (pˇrípadnˇe klientu jiné služby; záleží, jakou službu využívá) objeví zpráva a tím i kontakt na novˇe vytvoˇrený simulátor (SimServer). • getsims: pˇríkaz vypíše jména všech simulátor˚u, které jsou vytvoˇreny uživatel. • simsinfo: pˇríkaz vypíše informace o všech simulátorech (SimServerech) jako cˇ as jejich vytvoˇrení, dobu bˇehu a komentáˇr. • Pˇríkazy pro ovládání konkrétního SimSeveru registrovaného na uživatele: – siminfo: pˇríkaz vypíše informace o zadaném simulátoru jako cˇ as jeho vytvoˇrení a dobu bˇehu.


31

– history: simulátor zašle historii zpráv daného simulátoru. – state: komponenta SimServer zašle uživateli sv˚uj aktuální stav. – autostate: pˇríkaz nastaví automatické zasílání stavu simulátoru uživateli po uplynutí zadaného cˇ asového intervalu. – kill: pˇríkaz zruší komponentu SimServer. 3.2.3.7

Komponenta SimServerManager

SimServerManager je komponenta, která spravuje komponenty SimServer a je komunikaˇcním uzlem mezi SimServer a ostatními komponentami (viz obrázek ??). Tato komponenta je zodpovˇedná za vytváˇrení a rušení jednotlivých komponent SimServer. Uživatelský pˇrístup k této komponentˇe má pouze uživatel root. Pomocí této komponenty m˚uže root provádˇet následující pˇríkazy: • info: pˇríkaz vypíše poˇcet všech komponent SimServer, tedy poˇcet všech simulátor˚u. • userinfo: pˇríkaz vypíše poˇcet všech komponent SimServer, které jsou zaregistrovány na zadaného uživatele. • killsim: pˇríkaz zruší komponentu SimServer, která odpovídá zadanému parametru • killusersim: pˇríkaz zruší všechny komponenty SimServer, které jsou zaregistrovány na daného uživatele • killall: pˇríkaz zruší všechny komponenty SimServer 3.2.3.8

Komponenta UserManager

UserManager je komponenta, která spravuje komponenty User a je komunikaˇcním uzlem mezi User a ostatními komponentami. Pomocí této komponenty m˚uže root provádˇet následující pˇríkazy: • addUser: pˇríkaz vytvoˇrí novou komponentu User, která odpovídá zadanému parametru • deleteUser: pˇríkaz zruší komponentu User, která odpovídá zadanému parametru • addUsers: pˇríkaz vytvoˇrí komponenty User, které odpovídají zadaným parametr˚um • deleteUsers: ˇríkaz zruší komponenty User, které odpovídají zadaným parametr˚um 3.2.3.9

Komponenta Connection

Komponenta Connection zajišt’uje spojení mezi uživatem a Simonne pomocí dané komunikaˇcní služby. Jedna komponenta Connection má na starosti jednu komunikaˇcní službu. Také obhospodaˇruje všechna konta dané služby, které jsou pro Simonne na serveru dané služby vytvoˇreny. Komponenta Connection vytváˇrí a ruší jednotlivé úˇcty pro všechny komponenty. Vytváˇrení a rušení úˇctu pˇrináší urˇcité problémy. Emailové spojení je typickým. Emailové servery nepodporují vytváˇrení nebo rušení uživatelských kont pomocí emailu. A navím u naprosté vˇetšiny emailových server˚u je automatické správa kont nemožná. Emailové servery umožˇnují vytváˇret klientská konta v drtivé vˇetšinˇe pouze pomocí grafického rozhraní,


32

Obrázek 3.13: Propojení mezi uživateli a jednotlivými komponentami.

ˇ které je pro automatizaci naprosto nevhodné. Rešením by byl server, který by umožˇnoval vytvoˇrení (rušení) konta pomocí pˇríkazové ˇrádky. Pˇríkazy pro vytváˇrení a rušení kont by byly spouštˇeny lokálnˇe nebo pˇres SSH (v pˇrípadˇe vzdáleného serveru). Jabber spojení tímto neduhem netrpí. Vytváˇrení a rušení uživatelských kont je souˇcástí protokolu a není tˇreba použít jiný typ služby (jiný komunikaˇcní protokol). Pro vytvoˇrení nového konta staˇcí vytvoˇrit spojení se serverem a poslat specifickou zprávu obsahující jméno konta a heslo. Naopak pro zrušení konta je tˇreba se po pˇripojení pˇrihlásit jménem a heslem k danému kontu a opˇet zaslat specifickou zprávu. Pokud komponenta zareaguje na MessageEvent a její typ (MessageType) je ´TO-SEND´, odešle ji uživateli. Adresa uživatelova konta se zjistí z komponenty, která tuto zprávu poslala. Ta obsahuje referenci uživatele, který si ji zaregistroval. Pˇríjem zpráv od uživatele není problém. Každá komponenta má na serveru dané služby vlastní konto, pomocí kterého pˇrijímá zprávy. Pokud na toto konto dorazí zpráva, komponenta connection ji pˇrijme z daného serveru a podle obsahu zprávy vytvoˇrí zprávu (Message) a událost (MessageEvent), kterou zašle cílové komponentˇe. 3.2.3.10

Komponenta ConnectionController

Tato komponenta slouží pouze jako pˇrípojný bod pro vˇetšinu komponent (viz obrázek ??).

ˇ Cást III

Závˇer

33

ˇ KAPITOLA 4. ZÁVER

34

4 Závˇer 4.1 Shrnutí práce Tématem této práci bylo navázání na již existující simulátor neuronových sítí Simonne a rozšíˇrení tohoto simulátoru o možnost komunikace pˇres internet nebo lokální sít’. Komunikaˇcní cˇ ást simulátoru je navržena s ohledem na použitelnost ve výuce. Nepˇrináší nutnost dalších komunikaˇcních pˇríkaz˚u pro ovládání svého Simonne konta. Uživateli prakticky staˇcí znalost jediného pˇríkazu (pro vytvoˇrení simulátoru). Použití Instant Messaging služby Jabber pro komunikaci s klientem pˇrineslo velmi zajímavé vlastnosti. Pˇredevším je to možnost použití dnes tak rozšíˇrených IM klient˚u (jako napˇríklad ICQ). Dále je to rychlost komunikace, která je real-time. Komunikaˇcní cˇ ást simulátoru lze velmi jednoduše rozšíˇrit o další služby. Podmínkou je služba, u které je možno vzdálenˇe vytváˇret nebo mazat uživatelská konta. Toto je daˇn za snížení nárok˚u na uživatele pro práci se Simonne. Rozšíˇrení se týká nejenom komunikace s uživatelem, ale i cˇ ásti Simonne. Pokud by se ukázalo potˇrebným, lze k Simonne pˇripojit cˇ ásti, které pˇreberou nˇekteré administraˇcní úkoly (napˇríklad rušení dlouho nepˇripojených uživatel˚u nebo automatické vytváˇrení statistik).

Obrázek 4.1: Komunikace uživatele pomocí Instant messaging klienta se Simonne.

ˇ KAPITOLA 4. ZÁVER

35

4.2 Budoucnost Se simulátorem bylo provedeno v praxi jen málo simulací. Je zapotˇrebí dlouhodobˇejších pokus˚u, aby se otestovala robustnost serveru a jeho stabilita ve všech smˇerech. Nˇekteré cˇ ásti této práce poukázaly na možnosti rozšíˇrení: • GUI (graphic user interface): Textové uživatelské rozhraní je v dnešní dobˇe nedostaˇcující. Pro základní simulace postaˇcí, ale pro nasazení ve výuce, kdy se Simonne budou pracovat zaˇcáteˇcnící v oboru neuronových sítí se mohou cítit ztraceni. Proto by bylo vhodné rozšíˇrit stávající GUI pro potˇreby webové aplikace. Vytvoˇrení klienta – appletu pro spouštˇení ve webovém prohlížeˇci. Applet by komunikoval se Simonne pomocí protokolu Jabber. Po pˇrihlášení se automaticky stáhnou informace o bˇežících simulátorech a jejich historie. • Klient pro správu Simonne: Pokud bude systém používán dlouhodobˇe vˇetším množstvím uživatel˚u, ukáže se jako nezbytnost vytvoˇrení klienta pro správu Simonne. Ten by mˇel mít speciální funkce jako vytváˇrení statistik o uživatelích a bˇežících simulátorech. • Load balancing: Pokud bude systém Simonne využívat vˇetší množství uživatel˚u, je potˇreba vylepšit rozvrstvení výkonu do jednotlivé simulátory. • Vylepšení správy uživatelských kont: Nastavení uživatelských kont se prozatímnˇe úkládá do XML souboru. Je potˇreba tyto soubory zabezpeˇcit, pˇrípadnˇe je nahradit databází. Ta by mohla být propojena s již existujícími seznamy uživatel˚u.

ˇ Cást IV

Pˇrílohy

36

ˇ PRÍRU ˇ ˇ ˇ PRÍLOHA A. INSTALACNÍ CKA

37

A Instalaˇcní pˇríruˇcka Aplikace je distribuována ve formˇe spustitelného jar souboru pojmenovaného simonne.jar a adresáˇre conf, který obsahuje další nutné souˇcásti. K jejímu spuštˇení je nutné mít nainstalované prostˇredí pro bˇeh program˚u v Javˇe. Toto prostˇredí - Java Runtime Environment, je k dipozici zdarma na internetových stránkách Javy - java.sun.com. Ovˇeˇrení, jestli je nainstalováno lze provést pˇríkazem java -version, který vypíše jeho verzi. Další podmínkou pro chod aplikace je nutné mít naistalovaný Jabber server. Doporuˇcuji použít server ejabberd, který lze stáhnout ze stránek ejabberd.jabber.ru. Tento server je možné stáhnout zdarma a jsou k dispozici verzi pro operaˇcní systémy Windows, MacOSX, Linux a BSD. Po instalaci serveru je tˇreba otestovat, zda je povoleno vytváˇrení nových uživatel˚u. To m˚uže být otestováno bud’ libovolným Jabber klientem, kterým zkusíme vytvoˇri na tomto serveru nové konto nebo musí být zkontrolováno nastavení serveru - konkrétnˇe položka register. Ta musí být povolena (v pˇrípadˇe serveru ejabberd je nastaveno na allow). Aplikaci staˇcí nakopírovat do libovolného adresáˇre. Program ke svému bˇehu potˇrebuje adresáˇr conf, který musí být ve stejném adresáˇri jako soubor simonne.jar. Pro správný chod aplikace je nutné, aby mˇel program právo cˇ tení i zápisu v adresáˇri conf. Dalším krokem je nastavení konfiguraˇcního souboru. V souboru je nutno nastavit položky pro Jabber server - adresu serveru a port, na kterém služba bˇeží. V souboru je také nutné nastavit parametry uživatele root, který komunikuje se základními komponentami.

ˇ PRÍLOHA B. OBSAH CD

38

B Obsah CD Tato pˇríloha obsahuje seznam adresáˇru˚ na CD se struˇcným obsahem.

doc/ fig/ - obrázky použité v práci ⋆ thesis.pdf - text této diplomové práce v PDF install/ install.txt - pokyny pro instalaci ⋆ programs/ - programy potˇrebné k instalaci simonne/ ⋆ build - pˇreložená aplikace ⋆ conf - konfiguraˇcní soubory ⋆ lib ⋆ src - zdrojové kódy

ˇ PRÍLOHA C. SEZNAM LITERATURY

39

C Seznam literatury [1] AOL. Acceptable use policy (politika použití). www.icq.com/legal/policy.html. [2] M. Dvoˇrák. Návrhové vzory objekty.vse.cz/Objekty/Vzory.

(design

patterns)

-

diplomová

práce.

ˇ [3] J. Koutník. Implementation of the goloko neural network. Master’s thesis, Praha, CVUT FEL, Katedra poˇcítaˇcu˚ , 2002. ˇ [4] J. Trávník. Kompilátor pro neuronové sítˇe. Master’s thesis, Praha, CVUT FEL, Katedra poˇcítaˇcu˚ , 2004. ˇ [5] P. Vyskoˇcil. Simonne gui. Master’s thesis, Praha, CVUT FEL, Katedra poˇcítaˇcu˚ , 2003. [6] Wikipedia. Aim. www.en.wikipedia.org/wiki/AIM. [7] Wikipedia. Email. www.en.wikipedia.org/wiki/Email. [8] Wikipedia. Google talk. www.en.wikipedia.org/wiki/Google_talk. [9] Wikipedia. Icq. www.en.wikipedia.org/wiki/ICQ. [10] Wikipedia. Icq use policy. www.en.wikipedia.org/wiki/ICQ#External_links. [11] Wikipedia. Instant messaging. www.en.wikipedia.org/wiki/Instant_messaging. [12] Wikipedia. Jabber. www.en.wikipedia.org/wiki/Jabber. [13] Wikipedia. Jabber de. www.de.wikipedia.org/wiki/Jabber. [14] Wikipedia. Msn messenger. www.en.wikipedia.org/wiki/MSN_messenger. [15] Wikipedia. Porovnání instant messaging protokol˚u. www.en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols. [16] Wikipedia. Rmi. www.en.wikipedia.org/wiki/RMI. [17] Wikipedia. Technologie klient-server. www.en.wikipedia.org/wiki/Client-server.

České Vysoké Učení Technické Fakulta Elektrotechnická. Diplomová práce. Marek Hudík. Vedoucí práce: Ing. Jan Koutník

Recommend Documents