VŠB Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky

ˇ – Technická univerzita Ostrava VSB Fakulta elektrotechniky a informatiky Katedra informatiky

Klientsk´ aˇ c´ ast objektovˇ e orientovan´ eho datab´ azov´ eho syst´ emu

2002

Lum´ır N´ avrat

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tuto diplomovou práci vypracoval samostatnˇe. Uvedl jsem vˇsechny literárn´ı prameny a publikace, ze kter´ ych jsem ˇcerpal.

datum: 7.5.2002

podpis:

Abstrakt

S rozvojem informaˇcn´ıch technologi´ı a ˇcastˇejˇs´ım pouˇz´ıván´ım objektov´ ych technologi´ı se dosavadn´ı ukládán´ı dat do klasick´ ych relaˇcn´ıch databáz´ı stává problémem. Tato práce si klade za c´ıl navrhnout a implementovat uˇzivatelské rozhran´ı objektové databáze JUMBO. Rozhran´ı by mˇelo umoˇzn ˇovat prohl´ıˇzen´ı a manipulaci s daty jiˇz vytvoˇren´ ych aplikac´ı. Aplikace je naprogramov´ ana v jazyce JAVA a pro komunikaci se serverem pouˇz´ıvá protokol SOAP.

Kl´ıˇ cov´ a slova JUMBO, JAVA, JIVE, objektová databáze, ODMG, SOAP, uˇzivatelské rozhran´ı, klient

Abstrakt

Expansion of the information technologies and more often using object technologies present saving data into classical Relational Database state problem. This thesis behind aim propose and implement user interface for the object database JUMBO. Interface would have enable browsing and manipulation data which are already created by the application. Application was written in the language JAVA and use for the communication with a server protocol SOAP.

Keywords client, JUMBO, JAVA, JIVE, object database, ODMG, SOAP, user interface

Seznam pouˇ zit´ ych zkratek

BLOB Binary Large Object CD Compact Disc DTD Document Type Declaration GMT Greenwich Mean Time HTTP Hypertext Transfer Protocol ODL Object Definition Language ODMG Object Database Management Group OID Object Identifier OIF Object Interchange Format ˇ ˇ OO SRBD Objektovˇe orientovan´ y SRBD OMG Object Management Group OQL Object Query Language RPC Remote Procedure Call SMTP Simple Mail Transfer Protocol SQL Structured Query Language ˇ ızen´ı Báze Dat ˇ SRBD Systém R´ URI Uniform Resource Identifier XML Extended Markup Language

Obsah ´ 1 Uvod

4

2 Pouˇ zit´ e technologie

5

2.1

2.2

Systémy ˇr´ızen´ı báze dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

Logické datové modely . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.2

Objektovˇe relaˇcn´ı model . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.3

Objektov´ y model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Standard ODMG a jeho objektov´ y model . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.2

Základn´ı prvky objektového modelu . . . . . . . . . . . . . . . . . . . . .

8

2.2.3

Specifikace a implementace typ˚ u . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.4

Podtypy a dˇediˇcnost chován´ı . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.5

Extenty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.6

Objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.7

Atributy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.2.8

Vztahy

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

13

2.2.9

Operace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

OBSAH

2

2.3

Databázov´ y systém JUMBO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3.1

Struktura objekt˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

Protokol SOAP (Simple Object Access Protocol) . . . . . . . . . . . . . . . . . .

23

2.4

2.4.1

´ Uvod

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

23

2.4.2

Model v´ ymˇeny zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

2.4.3

Envelope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

2.4.4

Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

2.4.5

Body . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

2.4.6

Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.4.7

SOAP v HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

2.4.8

SOAP a RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3 JUMBO klient

33

3.1

Anal´ yza souˇcasného stavu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.2

Specifikace poˇzadavk˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.3

Anal´ yza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.3.1

Generátor formuláˇr˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.3.2

Komunikace se serverem . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

3.3.3

Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.3.4

Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

Návrh a implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.4.1

Rámec aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.4.2

Generátor formuláˇr˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

3.4

OBSAH

3

3.4.3

Generátor formuláˇr˚ u - SimpleTableGuiRenderer . . . . . . . . . . . . . . .

40

3.4.4

Akce klienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

3.4.5

Historie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

3.4.6

Komunikaˇcn´ı rozhran´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

3.4.7

Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

3.4.8

Nastaven´ı aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

3.4.9

Podp˚ urné tˇr´ıdy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

4 Z´ avˇ er

52

4.1

Zhodnocen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.2

Dalˇs´ı v´ yvoj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

A Uˇ zivatelsk´ a pˇ r´ıruˇ cka

54

A.1 Poˇzadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

A.2 Instalace a spuˇstˇen´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

A.3 Nastaven´ı aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

A.4 Práce s databáz´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

A.4.1 Procházen´ı mezi objekty . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

A.4.2 Vytváˇren´ı objekt˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

A.4.3 Editace objekt˚ u. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

A.4.4 Volán´ı operac´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

A.4.5 Mazán´ı objekt˚ u. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

B Obsah CD

58

´ 1. Uvod

S rozvojem v´ ypoˇcetn´ı techniky se stále zvyˇsuje potˇreba uchováván´ı dat a jejich n´ asledného zpracováván´ı. K obor˚ um, kter´ ym do této doby staˇcily nynˇejˇs´ı databáze zaloˇzené na relaˇcn´ım datovém modelu, se pˇridávaj´ı dalˇs´ı obory p˚ usob´ıc´ı v oblastech jako je napˇr. CAD, CASE, GIS a dalˇs´ı. Tyto systémy maj´ı jedno spoleˇcné. Potˇrebuj´ı uchovávat velké objemy dat. Proto zaˇcala ˇ b´ yt potˇreba po novém typu SRBD, kter´ y by byl zaloˇzen na u ´spˇechu souˇcasn´ ych systém˚ u, ale s lepˇs´ı podporou správy informac´ı. Struˇcné informace o dalˇs´ıch databázov´ ych technologi´ıch jako jsou digitáln´ı knihovny, historické databázové systémy je moˇzné nalézt v [4]. Kapitola 2 se zab´ yvá technologiemi, které se váˇzou k tématu této diplomové práce. Nejprve se ˇ ˇ velmi struˇcnˇe pokus´ım nast´ınit rozd´ıl mezi SRBD zaloˇzen´ ych na záznamov´ ych modelech a SRBD zaloˇzen´ ych na objektov´ ych modelech. Následnˇe se pˇresunu k popisu standardu ODMG, kter´ y je standardem pro objektové systémy. Pak bude následovat struˇcn´ y popis objektové datab´ aze JUMBO a na závˇer kapitoly se zm´ın´ım o komunikaˇcn´ım protokolu SOAP, kter´ y jsem pouˇzil pro komunikaci mezi serverem databáze JUMBO a m´ ym klientem. Kapitola 3 se nejdˇr´ıve zab´ yvá popisem aktuáln´ıho stavu systému. Po tomto seznámen´ı n´ asleduje anal´ yza ˇreˇsen´ı Jumbo klienta. Zbytek kapitoly je vˇenován návrhu a popisu ˇreˇsen´ı navrˇzeného klienta.

2. Pouˇ zit´ e technologie

2.1

Syst´ emy ˇ r´ızen´ı b´ aze dat

ˇ s´ı ukládán´ı dat na Tyto systémy umoˇzn ˇuj´ı definován´ı datov´ ych struktur a datov´ ych soubor˚ u. Reˇ médiu poˇc´ıtaˇce, umoˇzn ˇuj´ı manipulovat s daty a formátovat vstupn´ı a v´ ystupn´ı informace. Na tyto systémy se zamˇeˇr´ım z pohledu datov´ ych model˚ u, které implementuj´ı.

2.1.1

Logick´ e datov´ e modely

Modely zaloˇ zen´ e na z´ aznamech Do této kategorie m˚ uˇzeme zaˇradit dva modely: s´ıt’ov´ y model a relaˇcn´ı model. Rozd´ıl mezi tˇemito ’ modely je ve zp˚ usobu ukládán´ı dat. S´ıt ov´ y model vytváˇr´ı seznamovou strukturu se z´ ahlav´ım zat´ımco relaˇcn´ı model uchovává data ve formˇe tabulek.

Identifikace entit v relaˇ cn´ıch modelech Pˇ rirozen´ y kl´ıˇ c napˇr. jméno, rodné ˇc´ıslo, . . . – nelze zajistit absolutn´ı jednoznaˇcnost. – nelze zajistit existenci. – systémy nen´ı moˇzné spojovat pokud identifikátor ztrat´ı jednoznaˇcnost – identifikátor nelze jednoduˇse mˇenit. Pˇ ridˇ elen´ y identifik´ ator ˇclovˇekem nebo poˇc´ıtaˇcem – nutnost generován´ı identifikátoru – vytvoˇren´ y kl´ıˇc nemá sémantickou souvislost s entitou. Je pouze dalˇs´ı informac´ı v entitˇe.

2.1 Syst´ emy ˇ r´ızen´ı b´ aze dat

6

Nev´ yhody z´ aznamov´ ych model˚ u pˇredpokládá se, ˇze data lze popsat jednoduch´ ymi typy. Vˇetˇsinou ˇc´ıselné typy a ˇretˇezce. Rovnˇeˇz ˇcasto chyb´ı podpora pro strukturované typy a typ BLOB je pouze ˇcásteˇcné ˇreˇsen´ı. chyb´ı jim datové struktury, které pˇresnˇeji odráˇzej´ı strukturu informac´ı v reálném svˇetˇe pˇredpokládá se velk´ y poˇcet relativnˇe mal´ ych záznam˚ u, oproti CAD aplikac´ım, které maj´ı mnoho relac´ı s málo záznamy. vyjadˇruj´ı sp´ıˇse strukturu dat, neˇz jejich sémantiku, obt´ıˇzné ukládán´ı aplikaˇcn´ı k´ odu do databáze

2.1.2

Objektovˇ e relaˇ cn´ı model

Tento model se snaˇz´ı propojit vlastnosti klasického relaˇcn´ıho modelu s objektov´ ymi principy. ˇ Tento model je implementován v SRBD Oracle 9i. V rámci tohoto modelu je moˇzné pracovat se strukturovan´ ymi poloˇzkami (tabulky jsou chápány jako hodnoty). Tyto modely jsou velice populárn´ı z d˚ uvodu moˇznosti vyuˇzit´ı stávaj´ıc´ı relaˇcn´ı technologie, kterou pak jen rozˇs´ıˇr´ı o objektové vlastnosti.

2.1.3

Objektov´ y model

Tento model je zaloˇzen na u ´spˇechu souˇcasn´ ych objektov´ ych jazyk˚ u a technologi´ı. Model vych´ az´ı z poˇzadavku potˇreby modelován´ı následuj´ıc´ıch bod˚ u informace o entit´ ach re´ aln´ eho svˇ eta - velmi ˇcasto nen´ı moˇzné tuto entitu popsat jedin´ ym záznamem tvoˇren´ ym ˇc´ısly a ˇretˇezci vlastnosti entit - entity nejsou pouze textové a numerické a nemusej´ı b´ yt ani jednotypové. Jedna vlastnost m˚ uˇze m´ıt v´ıce typ˚ u (napˇr. plátce danˇe je jak fyzická, tak i právnick´ a osoba) vztahy mezi entitami - potˇreba ˇreˇsit modelován´ı obecn´ ych vztah˚ u typu M:N operace nad entitami - entity reálného svˇeta maj´ı své chován´ı, které je potˇreba uchovávat s atributy Identita objekt˚ u Objekt je jednoznaˇcnˇe identifikovateln´ y bˇehem celé doby své existence tzv. OID. Toto OID je generované systémem a nen´ı ho moˇzné bˇehem celé doby zmˇenit. Rovnˇeˇz nen´ı viditelné jak pro programátora tak ani pro koncového uˇzivatele.

2.2 Standard ODMG a jeho objektov´ y model

7

ˇ Probl´ emy objektov´ ych SRBD I pˇres jiˇz relativnˇe dlouh´ y v´ yvoj objektov´ ych databáz´ı, maj´ı tyto databázové systémy st´ ale problémy se prosadit. To je dáno nˇekolika faktory. Firmy velmi investovaly do jiˇz existuj´ıc´ıch relaˇcn´ıch technologi´ı a s t´ım souvis´ı problém migrace dat mezi tˇemito systémy. Dalˇs´ım problémem je doposud chybˇej´ıc´ı jednotná standardizace pojmu Objektovˇe orientovan´ y datov´ y model“. ” Dneˇsn´ı systémy zaloˇzené na záznamov´ ych modelech maj´ı, d´ıky své dlouhé existenci, jiˇz impleˇ mentovány velmi efektivn´ı techniky, které je pro OO SRBD nutné teprve vyvinout. Objektovˇe orientovan´ y model je sloˇzitˇejˇs´ı a proto i jeho realizace je nároˇcnˇejˇs´ı. Rovnˇeˇz uˇzivatelská rozhran´ı ˇ ˇ OO SRBD zat´ım nedosahuj´ı kvalit souˇcasn´ ych relaˇcn´ıch SRBD.

2.2

Standard ODMG a jeho objektov´ y model

2.2.1

Historie

Historie objektov´ ych databáz´ı se zaˇc´ıná odv´ıjet jiˇz v 70. letech minulého stolet´ı, kdy vznikl standard CODASYL pro s´ıt’ové databáze. Tento standard sice nebyl objektov´ y ale je moˇzné v nˇem nalézt nˇekteré náznaky budouc´ıch objektov´ ych databáz´ı. Prvn´ı v´ yzkumy pˇr´ımo v oblasti ˇ OO SRBD pak zaˇc´ınaj´ı poˇcátkem 80. let. Na konci tˇechto let vznikaj´ı prvn´ı komerˇcn´ı systémy (napˇr. ObjectDesign, Versant, O2 , Objectivity). Organizaci ODMG zaloˇzil v roce 1991 Rick Cattell. O rok pozdˇeji vzniká standard SQL 92 pro relaˇcn´ı databáze a zaˇc´ıná v´ yvoj na standardu SQL3 pro objektové databáze. V následuj´ıc´ım roce je zveˇrejnˇen prvn´ı standard ODMG 93. Ten byl v roce 1997 upraven na ODMG 2 a v roce 1999 byla zveˇrejnˇena zat´ım posledn´ı verze tohoto standardu pod názvem ODMG 3 ([2]).

ˇ asti standardu C´ Object model — vycház´ı z objektového modelu organizace OMG a definuje sémantiku, kter´ a ˇ pak m˚ uˇze b´ yt pˇr´ımo pouˇzita v OO SRBD. Dále popisuje, jak jsou objekty identifikovány a jak mohou vstupovat do vztah˚ u. Object Specification Languages Object Definition Language — pouˇz´ıvá se pro definici objekt˚ u a jejich typ˚ u v r´ amci objektového modelu Object Interchange Format — pouˇz´ıvá se pro popis zp˚ usobu, jak data ukládat nebo ˇc´ıst ze souboru pˇr´ıpadnˇe mnoˇziny soubor˚ u


8

Object Query Language — deklarativn´ı (neproceduráln´ı) jazyk pro vyhledáván´ı a modifikaci obˇ jekt˚ u v OO SRBD. Vycház´ı z relaˇcn´ıho standardu SQL, ale je rozˇs´ıˇren o dalˇs´ı uˇziteˇcné vlastnosti pouˇzitelné v objektov´ ych databáz´ıch Language Bindings — definuje propojen´ı objektového modelu s programovac´ımi jazyky C++, JAVA, SmallTalk

2.2.2

Z´ akladn´ı prvky objektov´ eho modelu

objekt má unikátn´ı identifikátor (OID) liter´ al narozd´ıl od objektu nemá vlastn´ı identitu a je definován jen svou hodnotou objekty a literály se kategorizuj´ı podle sv´ ych typ˚ u. Typ definuje prvky se stejn´ ymi vlastnostmi a stejn´ ym chován´ım stav objektu je definován hodnotami sv´ ych vlastnost´ı. tj. atribut˚ u a vztah˚ u. chován´ı objekt˚ u je definováno sadou operac´ı, které lze nad objektem provést. Operace maj´ı vstupn´ı a v´ ystupn´ı parametry a mohou vracet hodnotu datab´ aze ukládá objekty a umoˇzn ˇuje jejich sd´ılen´ı v´ıce uˇzivateli a aplikacemi. Je zaloˇzena na schématu definovaném pomoc´ı jazyka ODL a obsahuje instance typ˚ u definovan´ ych schématem.

2.2.3

Specifikace a implementace typ˚ u

Specifikace typu Specifikace typu je implementaˇcnˇe nezávislá a je abstraktn´ım popisem operac´ı, v´ yjimek a vlastnost´ı, které bude moci vidˇet uˇzivatel tohoto typu. Interface (rozhran´ı) definuje pouze abstraktn´ı chován´ı typu. Liter´ al pro zmˇenu definuje pouze abstraktn´ı stav nebo hodnotu). Class (tˇr´ıda) je pr˚ unikem pˇredchoz´ıch dvou pojm˚ u a umoˇzn ˇuje definovat jak abstraktn´ı chován´ı, tak i stav (obr. 2.1).

Implementace typu Implementace typu se skládá z reprezentace a mnoˇziny metod, pˇriˇcemˇz nen´ı viditelná pro uˇzivatele. Reprezentace je datová struktura, která se definuje na základˇe mapován´ı do jazyka. Metody jsou pak tˇela operac´ı definovan´ ych ve specifikaci typu. Tyto metody definuj´ı veˇrejnˇe viditelné


9

Obrázek 2.1: Specifikace typu

chován´ı objektového typu. Rovnˇeˇz mohou existovat metody, které nejsou pˇr´ımou souˇc´ ast´ı specifikace typu. Typ m˚ uˇze m´ıt v´ıce neˇz jednu implementaci, ale m˚ uˇze b´ yt pouˇzita pouze jedna v daném programu (napˇr. jedna pro C++, druhá pro JAVu atd.)

2.2.4

Podtypy a dˇ ediˇ cnost chov´ an´ı

Stejnˇe jako v jin´ ych objektov´ ych modelech, tak i ODMG objektov´ y model obsahuje vazbu mezi typem a podtypem zaloˇzenou na dˇediˇcnosti. Tomuto vztahu se nˇekdy ˇr´ıká is-a vztah. Pro tento vztah bylo definováno, ˇze instance podtypu je zároveˇ n instanc´ı nadtypu a dále kaˇzd´ y objekt m´ a právˇe jeden nejv´ıce specifick´ y typ, kter´ y popisuje vˇsechny atributy a operace objektu. Model povoluje v´ıcenásobnou dˇediˇcnost pouze pro chován´ı objektu. Jak je vidˇet na obrázku 2.2 tato v´ıcenásobná dˇediˇcnost nen´ı moˇzná mezi tˇr´ıdami. ODL tˇr´ıdy jsou v c´ılovém implementaˇcn´ım jazyku mapovány na tˇr´ıdy, které mohou b´ yt pˇr´ımo instanciované, zat´ımco interface je typ, kter´ y pˇr´ımo instanciovat nelze. Dalˇs´ım vztahem ke vztahu is-a je vztah extends. Tento vztah definuje dˇediˇcnost mezi jednotliv´ ymi objektov´ ymi typy. Tento vztah povoluje pouze jednoduchou dˇediˇcnost mezi dvˇemi tˇr´ıdami, kdy dˇedˇená tˇr´ıda dˇed´ı vˇsechny vlastnosti a chován´ı ze své nadtˇr´ıdy.

2.2.5

Extenty

ˇ Extent typu je mnoˇzina vˇsech instanc´ı daného typu v OO SRBD. Jestliˇze objekt je instance typu A potom bude ˇclenem extentu typu A. Pokud bude typ A podtypem typu B, pak extent typu A bude podmnoˇzinou extentu typu B.


10

Obrázek 2.2: Vztah tˇr´ıda-interface

ˇ SRBD m˚ uˇze tento extent udrˇzovat automaticky, tj. m˚ uˇze pˇridávat do mnoˇziny novˇe vytvoˇrené instance nebo z této mnoˇziny tyto instance odeb´ırat, pokud byly smazány. Rovnˇeˇz je moˇzné vytváˇret a spravovat indexy pro zrychlen´ı pˇr´ıstupu k extentu.

2.2.6

Objekty

Vytv´ aˇ ren´ı objekt˚ u Pro vytváˇren´ı objekt˚ u se vyuˇz´ıvá návrhov´ y vzor Abstract Factory“, kter´ y dává moˇznost meto” dou new() implementovat v daném c´ılovém implementaˇcn´ım jazyku kód staraj´ıc´ı se o vytvoˇren´ı objektu. interface ObjectFactory { Object new(); }; Z následuj´ıc´ıho rozhran´ı dˇed´ı vˇsechny objekty v modelu a je tak implicitn´ım rozhran´ım pro vˇsechny objekty.


11

interface Object { enum Lock_Type(read,write,upgrade); void lock(in Lock_Type mode) raises(LockNotGranted); boolean try_lock(Lock_Type mode); boolean same_as(in Object anObject); Object copy(); void delete(); };

Identifik´ atory objekt˚ u (OID) Vˇsechny objekty maj´ı sv˚ uj identifikátor, kter´ ym jsou od sebe vˇzdy vzájemnˇe rozliˇsitelné. Abychom mohli porovnat tyto objekty slouˇz´ı k tomu metoda same_as() v´ yˇse uvedeného rozhran´ı Object. Identifikátor objektu se bˇehem celé ˇzivotnosti objektu nemˇen´ı. Tato podm´ınka plat´ı i pokud se u ´plnˇe zmˇen´ı obsah jeho atribut˚ u a vztah˚ u. Identifikátor se dále pouˇz´ıvá pro odkazy ˇ mezi objekty. Generován´ı identifikátoru je zajiˇst’ováno prostˇredky SRBD a aplikace jej m˚ uˇze jen ˇ vyuˇz´ıvat. Zde je vidˇet zásadn´ı rozd´ıl mezi primárn´ım kl´ıˇcem v relaˇcn´ıch SRBD a OID objektu.

Jm´ ena objekt˚ u Objekt˚ um lze pˇriˇradit nˇekolik jmen, které jsou aliasy pro identifikátory objekt˚ u. Tyto aliasy jsou vstupn´ımi body pro navigaci v databázi a jsou unikátn´ı v rámci celé databáze. Aliasy lze chápat jako globáln´ı jméno promˇenné v programovac´ıch jazyc´ıch. Nejsou definovány v rozhran´ı typu a nemaj´ı ani ˇzádn´ y vztah k hodnotám atribut˚ u objektu.

Doba ˇ zivota objekt˚ u Definuje dobu, po kterou je objekt˚ um pˇridˇelena pamˇet’. Objekty m˚ uˇzeme rozdˇelit do dvou skupin. Tranzient´ı objekty – existuj´ı pouze po dobu ˇcinnosti aplikace. Napˇr. lokáln´ı promˇenné v metodách nebo globáln´ı promˇenné procesu. Pˇridˇelován´ı pamˇeti ˇr´ıd´ı run-time programovac´ıho jazyka. Perzistentn´ı objekty – existuj´ı i po ukonˇcen´ı procesu, kter´ y jej vytvoˇril. Pˇridˇelován´ı pamˇeti ˇ ˇr´ıd´ı run-time systému SRBD. Doba ˇzivota objektu nen´ı závislá na typu objektu a tak je moˇzné, aby jeden typ mˇel souˇcasnˇe jak tranzientn´ı tak i perzistentn´ı instance. Tato doba pak m˚ uˇze b´ yt definovaná jiˇz pˇri vytvoˇren´ı objektu nebo dosaˇzitelnost´ı objektu.


12

Druhy objekt˚ u atomick´ e objekty jsou definované uˇzivatelem a standard nedefinuje ˇzádné zabudované atomické objekty kolekce obsahuj´ı instance atomického objektu, jiné kolekce nebo typu literálu. Vˇsechny prvky kolekce mus´ı b´ yt téhoˇz typu. – Set – neuspoˇrádaná mnoˇzina prvk˚ u, které se nesm´ı v kolekci opakovat – Bag – neuspoˇrádaná mnoˇzina prvk˚ u, které se mohou v kolekci opakovat – List – uspoˇrádan´ a mnoˇzina prvk˚ u, které se mohou v kolekci opakovat – Array – uspoˇrádaná mnoˇzina prvk˚ u, která mˇen´ı dynamicky velikost. K jednotliv´ ym prvk˚ um kolekce je moˇzné pˇristupovat na základˇe znalosti jejich um´ıstˇen´ı v kolekci – Dictionary – neuspoˇrádaná mnoˇzina páru kl´ıˇc-hodnota, pˇriˇcemˇz se nesm´ı kl´ıˇce opakovat strukturovan´ e typy – Date – datum – Interval – ˇcasov´ y interval, kter´ y je moˇzné pouˇz´ıvat s objekty Time a Timestamp. Interval se vytváˇr´ı metodou subtract_time definovanou v rozhran´ı Time. – Time – reprezentuje svˇetov´ y ˇcas v dané ˇcasové zónˇe. Internˇe se ˇcas ukládá v ˇcasové zónˇe GMT. – Timestamp – zapouzdˇruje objekty Date a Time

2.2.7

Atributy

Hodnotou atributu je vˇzdy literál, nebo OID. Atribut je abstraktn´ım stavem instance a nemus´ı tak vˇzdy odpov´ıdat datové struktuˇre (napˇr. atribut age v následuj´ıc´ım pˇr´ıkladu m˚ uˇze b´ yt implementován metodami, které zpracuj´ı atribut birthdate). Jelikoˇz atribut nemá vlastn´ı identitu nemohou atributy mezi sebou definovat vztahy. interface i_Person { attribute short age; }


13

class Person: i_Person { attribute Date birthdate; attribute string name; attribute enum gender {male, female}; attribute Address home_adress; attribute set phones; attribute Department dept; }

2.2.8

Vztahy

Vztahy se definuj´ı pouze mezi typy a mohou b´ yt pouze binárn´ı tj. 1:1, 1:N a M:N. Tyto vztahy ˇ jsou vˇzdy obousmˇerné a SRBD je zodpovˇedn´ y za dodrˇzován´ı referenˇcn´ı integrity tˇechto vztah˚ u. To znamená v naˇsem pˇr´ıkladˇe, ˇze v pˇr´ıpadˇe smazán´ı instance typu Professor mus´ı doj´ıt ke smaz´ an´ı vˇsech referenc´ı ve vˇsech instanc´ıch typu Course. Atributy typu Object, nebo kolekce objekt˚ u tak nezajiˇst’uj´ı referenˇcn´ı integritu. Následuj´ıc´ı pˇr´ıklad ukazuje zp˚ usob zápisu vztah˚ u. Je uveden zápis pro vztah 1:N, kdy profesor uˇc´ı nˇekolik kurz˚ u a kurz je uˇcen pouze jedn´ım uˇcitelem. Kl´ıˇcové slovo inverse identifikuje název vztahu na druhé stranˇe vazby. class Professor { ... relationship set teaches inverse Course::is_taught_by; ... }; class Course { ... relationship Profesor is_taught_by inverse Professor::teaches; ... };

2.2.9

Operace

Vedle atribut˚ u a vztah˚ u, které definuj´ı stav objektu je potˇreba definovat chován´ı objektu. Toto chován´ı je specifikováno mnoˇzinou signatur operac´ı. Tato signatura definuje jméno operace, jména a typy argument˚ u a jména generovan´ ych v´ yjimek. Operace je moˇzné definovat pouze pro jedin´ y typ, ale je moˇzné operace pˇretˇeˇzovat, takˇze m˚ uˇze existovat v jiném typu operace stejného jména. Pˇri volán´ı operace daného jména se provád´ı v´ ybˇer na základˇe nejv´ıce specifického typu.

2.3 Datab´ azov´ y syst´ em JUMBO

14

Obrázek 2.3: Vytváˇren´ı aplikace dle standardu ODMG3.0

2.3

Datab´ azov´ y syst´ em JUMBO

Jedn´ a se o experimentáln´ı objektovˇe orientovan´ y databázov´ y server, kter´ y vycház´ı ze standardu ODMG, pˇriˇcemˇz standard rozˇsiˇruje o podporu rol´ı a proces˚ u. Systém vznikl na v´ ysledc´ıch v´ yzkumného projektu V´ıcetypové objekty v objektovém datovém modelu.“ Tento projekt ” prob´ıhal v rozmez´ı let 1998 a 1999 na Vysokém uˇcen´ı technickém v Brnˇe. Struktura systému je znázornˇena na obrázku 2.4. Objekty v systému jsou specifikov´ any prostˇrednictv´ım rozhran´ı v jazyce ODL. Samotná implementace operac´ı je zajiˇst’ována jazykem JIVE, kter´ y vycház´ı z jazyka JAVA, kter´ y rozˇsiˇruje o programové konstrukce pro transparentn´ı manipulaci s tranzientn´ımi a perzistentn´ımi objekty. Modul je základn´ım prvkem aplikace. Pˇreloˇzen´ım jeho definiˇcn´ı ˇcást´ı napsané v jazyce ODL a pˇr´ısluˇsné implementace v jazyce Jive dostaneme binárn´ı modul. Tento binárn´ı modul m˚ uˇzeme pak v pˇr´ıpadˇe poˇzadavku nahrát do pamˇeti databázového serveru a spouˇstˇet pˇreloˇzené operace ve virtuáln´ım stroji jazyka Jive (JiveVM). Databázov´ y server umoˇzn ˇuje komunikovat s klienty pomoc´ı dvou protokol˚ u. Implementaˇcnˇe starˇs´ım je protokol HTTP, kter´ y se pouˇz´ıvá pouze pro experimentován´ı a testován´ı serveru.


15

Obrázek 2.4: Struktura databázového serveru

ˇ V rámci této diplomové práce vznikl uˇzivatelsk´ y klient a Petr Sula ve své diplomové pr´ aci pracoval na programátorském klientovi, kter´ y umoˇzn ˇuje navrhovat schémata modul˚ u v jazyce ODL. Oba klienti komunikuj´ı se serverem protokolem SOAP. Systém po spuˇstˇen´ı nejprve inicializuje pˇrekladaˇc a databázové jádro. Následnˇe je vytvoˇren popis metadat (modul ODLMetaObjects) ten je vloˇzen do systému. Takto je moˇzné reprezentovat databázové schéma, vˇcetnˇe schématu metadat popisem sama sebe. Nejvˇetˇs´ı v´ yhodou tohoto postupu je moˇznost implementace mnohem speciálnˇejˇs´ıch operac´ı databázového schématu pˇr´ımo v jazyce Jive bez nutnosti cokoli programovat v hostuj´ıc´ım jazyce systému C++. Sa-


16

mozˇrejmˇe je moˇzné implementovat operace v nativn´ım jazyce (napˇr. z d˚ uvodu poˇzadavku efektivity n´ızko´ urovˇ nov´ ych operac´ı).

Role Jak jiˇz bylo uvedeno, Jumbo pouˇz´ıvá k popisu rozhran´ı objekt˚ u jazyk ODL. Tento jazyk d´ ale rozˇsiˇruje o koncept rol´ı. Zp˚ usob z´ apisu je uveden v následuj´ıc´ım pˇr´ıkladu. Role jsou v run-timové hierarchii reprezentovány hlavn´ım objektem, kter´ y tvoˇr´ı koˇren stromu objekt˚ u. Role funguj´ı v podstatˇe jako rozˇs´ıˇren´ı stromu dˇediˇcnosti, vytvoˇreného bˇehem pˇrekladu, bˇehem bˇehu systému. Role dˇed´ı operace a vlastnosti svého základn´ıho objektu. Proto pro kaˇzd´ y pˇr´ıstup k tomuto objektu skrz roli je potˇreba udrˇzovat skrytou referenci z role na tento objekt. Komunikace se samotn´ ym objektem m˚ uˇze pak prob´ıhat nepˇr´ımo pˇres jakoukoliv roli, která reprezentuje objekt. Adresovaná role bud’ zpracuje poˇzadavek sama, nebo pˇr´ıpadnˇe jej pˇredá rodiˇcovskému objektu. Role jsou tak schopné nahradit vˇetˇsinu vlastnost´ı v´ıcenásobné dˇediˇcnosti, která nen´ı podporována v standardu ODMG v3.0. Nav´ıc je moˇzné role pˇridávat a odeb´ırat dynamicky bˇehem ˇzivotn´ıho cyklu objektu a tak lze velmi jednoduˇse modelovat ˇzivotn´ı cyklus objekt˚ u v re´ alném svˇetˇe.

class Student roleof Osoba relationship Skola attribute long attribute TypStudia };

(extent studenti) { skola inverse studenti; rocnik; studium;

Dalˇs´ım rozˇs´ıˇren´ım jsou kvalifikované role. Ty vycházej´ı z poˇzadavku modelován´ı situac´ı kdy jeden objekt hraje tutéˇz roli v´ıcekrát (napˇr. osoba studuje v´ıce ˇskol). V takovém pˇr´ıpadˇe je nutné jednoznaˇcnˇe urˇcit o kterou roli se jedná. Toto rozˇs´ıˇren´ı zat´ım nen´ı v jazyce Jive implementov´ ano.

Jazyk Jive Standard ODMG nedefinuje vlastn´ı jazyk pro manipulaci s daty, ale jen specifikuje mapov´ an´ı do jazyk˚ u C++, Java a Smalltalk. Typické schéma implementace aplikace je pak znázornˇeno na obrázku 2.3. I kdyˇz tento pˇr´ıstup je vcelku pˇrijateln´ y, nenaplˇ noval plnˇe principy ortogonality perzistentn´ıch jazyk˚ u [3]. Z tohoto d˚ uvodu byl zvolen zcela odliˇsn´ y pˇr´ıstup a byl vytvoˇren speci´ aln´ı manipulaˇcn´ı jazyk Jive, kter´ y tyto principy splˇ nuje v souladu se standardem ODMG. Jazyk Jive je tedy ortogonáln´ım rozˇs´ıˇren´ım jazyka Java s následuj´ıc´ımi pˇridan´ ymi vlastnostmi.


17

- Jive je pevnˇe svázan´ y se standardn´ı definic´ı jazyka ODL, takˇze nen´ı zde ˇzádn´ y problém s impledanc´ı typu [3]. Jive podporuje vˇsechny typy a konstrukce jazyka ODL vˇcetnˇe vztah˚ u mezi objekty. - Jive obsahuje podporu pro ODMG 3.0 OQL, coˇz zajiˇst’uje plnou kontrolu dotaz˚ u jiˇz bˇehem pˇrekladu. - Virtuáln´ı stroj JiveVM pˇr´ımo podporuje instrukce orientované na specifické datab´ azové konstrukce (napˇr. dotazy, datové operátory).

2.3.1

Struktura objekt˚ u

Systémové a metaobjekty databáze JUMBO jsou tvoˇreny dvˇemi moduly. Modulem ODL a modulem ODLMetaObjects. Jak jiˇz bylo uvedeno tyto moduly jsou vytváˇreny okamˇzitˇe po inicializaci systému a d´ıky tomu je moˇzné k nim pˇristupovat stejnˇe jako k jin´ ym objekt˚ um v datab´ azi. Systém zat´ım plnˇe neimplementuje standard ODMG a to hlavnˇe v oblasti transakc´ı, ˇr´ızen´ı spoleˇcného pˇr´ıstupu a jmenného prostoru typ˚ u. Posledn´ı vlastnost se projevuje t´ım, ˇze veˇskeré objekty a typy jsou definované a viditelné v rámci celého modulu.

Modul ODL Tento modul obsahuje typy Object, Blob, Extent, CodeBlob a TextBlob. Jednotlivé z´ avislosti tˇr´ıd je moˇzné vidˇet na obrázku 2.5.

Obrázek 2.5: Schéma tˇr´ıd v modulu ODL

Object

typ kter´ y implicitnˇe implementuj´ı vˇsechny systémové i uˇzivatelské typy.


18

Blob, CodeBlob, TextBlob typy slouˇz´ı k uloˇzen´ı binárn´ıch dat do databáze.

Extent

typ pro ukládán´ı extent˚ u. (viz 2.2.5)

Modul ODLMetaObjects Tento druh´ y systémov´ y modul definuje metaobjekty standardu ODMG a vytváˇr´ı tak datab´ azové schéma systému.

MetaObject Obecn´ y metaobjekt, kter´ y poskytuje spoleˇcné vlastnosti vˇsem metaobjekt˚ um. Jedn´ a se o atributy name a comment.

Obrázek 2.6: Schéma dˇedˇen´ ych tˇr´ıd z MetaObject

Module v´ ychoz´ı bod pro popis metaschématu dané aplikace. Vˇse co popisuje data je viditelné pouze v rámci daného modulu. Modul má atribut sourceFile, kter´ y obsahuje jméno souboru s ODL popisem.

Interface jeden z nejd˚ uleˇzitˇejˇs´ıch typ˚ u. Definuje abstraktn´ı chován´ı aplikaˇcn´ıch objekt˚ u

Class rozˇsiˇruje Interface o abstraktn´ı stav objekt˚ u. Jedn´ım z atribut˚ u je is_role, kter´ y urˇcuje, ˇze instance tˇr´ıdy je rol´ı. Dalˇs´ım atributem je extents, kter´ y obsahuje referenci na extent tˇr´ıdy. Atribut source pak obsahuje referenci na Blob objekt obsahuj´ıc´ı zdrojov´ y kód tˇr´ıdy.


19

Obrázek 2.7: Schéma vazeb typu Module

Obrázek 2.8: Schéma vazeb typ˚ u Interface a Class

Property abstraktn´ı typ, kter´ y zastˇreˇsuje typy Attribute a Relationship. Obsahuje atribut type, kter´ y definuje typ vlastnosti.

Attribute vlastnost, která uchovává informace o stavu. Má atribut read_only, kter´ y urˇcuje, ˇze neexistuje moˇznost zmˇenit hodnotu atributu.

Relationship vlastnost, která realizuje obousmˇernou vazbu mezi typy. Má atribut traversal, kter´ y obsahuje jméno vazby u druhého objektu.

Operation

typ modeluje podporu chován´ı aplikaˇcn´ıch objekt˚ u.


20

Obrázek 2.9: Schéma vazeb typ˚ u Property,Attribute,Relationship

Exception

typ popisuje v´ yjimky, které mohou operace volat.

Code typ popisuje binárn´ı kód operac´ı. Vlastn´ı kód v jazyce Jive je v atributu code. Dalˇs´ı atributy stack_size, var_size a is_native bl´ıˇze urˇcuj´ı vlastnosti operace v JiveVM.

Obrázek 2.10: Schéma vazeb mezi typy Operation, Exception a Code

Constant

zajiˇst’uje popis konstanty v modulu pomoc´ı atribut˚ u the_value a type.

TypeDefinition tento typ má zajistit podporu aliasu daného typu.

Enumeration je strukturovan´ y typ, kter´ y realizuje v´ yˇctov´ y typ. Prvky v´ yˇctu jsou uloˇzené v atributu consts. Prvkem mohou b´ yt jen literály typu string.


Strukturovan´ e typy jedná se o typy Union, Structure a s t´ım souvisej´ıc´ı typ Member.

Uk´ azka definice modulu pro syst´ em JUMBO module Pokus { class Kontakt (extent kontakty) { attribute string adresa; }; class Osoba extends Kontakt (extent osoby) { attribute string jmeno; attribute string adresa; attribute char znak; string kdo_jsi(); Student do_skoly(in Skola skola); Zamestnanec do_prace(in Firma firma, in long plat); }; class Firma extends Kontakt (extent firmy) { attribute string nazev; attribute string adresa; attribute unsigned long ico; attribute set kontakty; relationship set zamestnanci inverse firma; void pridej_kontakt(in Kontakt x); }; class Skola extends Firma (extent skoly) { relationship set<Student> studenti inverse skola; }; class Zamestnanec roleof Osoba (extent zamestnanci) { relationship Firma firma inverse zamestnanci; attribute long plat; }; enum TypStudia { bc,mgr,dr };

21


class Student roleof Osoba relationship Skola attribute long attribute TypStudia };

(extent studenti) { skola inverse studenti; rocnik; studium;

} // module pokus

Uk´ azka implementace funkc´ı pˇ redchoz´ıho modulu implementation module Pokus { class Firma { void pridej_kontakt(in Kontakt x) { kontakty.insert_element(x); } // pridej_kontakt }; // Firma class Osoba { string kdo_jsi() { return "Osoba: " + jmeno; } // kdo_jsi Student do_skoly(in Skola skola) { var Student student = newRole Student; student.skola = skola; student.rocnik = 1; return student; } // do_skoly Zamestnanec do_prace(in Firma firma, in long plat) { var Zamestnanec zam = newRole Zamestnanec; zam.firma = firma; zam.plat = plat; return zam; } // do_prace }; // Osoba

22

2.4 Protokol SOAP (Simple Object Access Protocol)

23

class Zamestnanec { string kdo_jsi() { return "Zamestnanec: " + jmeno + " - " + firma.nazev; } // kdo_jsi }; // Zamestnanec class Student { string kdo_jsi() { return "Student: " + jmeno + " - " + skola.nazev + ", rocnik " + rocnik; } // kdo_jsi }; // Student } // Pokus

2.4

Protokol SOAP (Simple Object Access Protocol)

2.4.1

´ Uvod

SOAP je protokol poskytuj´ıc´ı jednoduch´ y mechanismus pro v´ ymˇenu informac´ı v decentralizovaném, distribuovaném prostˇred´ı. Protokol pouˇz´ıvá XML a sám o sobˇe nedefinuje ˇz´ adnou aplikaˇcn´ı sémantiku. Poskytuje jen modulárn´ı model pro zapouzdˇren´ı dat a mechanismus pro kódován´ı tˇechto dat v rámci modulu. To umoˇzn ˇuje protokolu SOAP b´ yt pouˇz´ıván v r˚ uzn´ ych systémech od systému pro zas´ılán´ı zpráv aˇz po RPC. Protokol m˚ uˇze b´ yt rovnˇeˇz pouˇzit´ y v kombinaci s jin´ ymi protokoly (napˇr. HTTP, SMTP). Tento protokol byl standardizován a je udrˇzov´ an organizac´ı W3C. Samotn´ y vznik protokolu byl podm´ınˇen potˇrebou jednoduchého protokolu, kter´ y by byl nezávisl´ y na platformˇe jak systémové, tak i programové. Na samotném vzniku protokolu se tak pod´ılely firmy jako je IBM ˇci Microsoft. V dneˇsn´ı dobˇe s rozvojem internetu a webov´ ych sluˇzeb se tento protokol stává populárnˇejˇs´ım a k tomu pˇrisp´ıvá i mnoˇzstv´ı implementac´ı pod r˚ uzn´ ymi programovac´ımi jazyky. Protokol SOAP se skládá z následuj´ıc´ıch ˇcást´ı: SOAP Envelope – (viz 2.4.3) definuje aplikaˇcn´ı rámec vyjadˇruj´ıc´ı co je obsahem zpr´ avy, kdo by ji mˇel zpracovat a zda je obsah povinn´ y nebo voliteln´ y


24

SOAP Encoding rules – definuj´ı pravidla pro serializaci1 aplikaˇcn´ıch datov´ ych typ˚ ua umoˇznit tak jejich pˇrenos. SOAP RPC – definuje pravidla, které lze pouˇz´ıt bˇehem vzdáleného volán´ı funkc´ı a z´ıskáván´ı odpovˇed´ı na nˇe. Protokol byl navrˇzen jako jednoduch´ y a rozˇsiˇriteln´ y. To má za následek chybˇej´ıc´ı podporu nˇekter´ ych vlastnost´ı tradiˇcn´ıch systém˚ u pro pˇredáván´ı zpráv a distribuovan´ ych systém˚ u. Následuj´ıc´ı dva pˇr´ıklady ukazuj´ı, jak m˚ uˇze vypadat poˇzadavek a odpovˇed v tomto protokolu.

SOAP poˇ zadavek v protokolu HTTP POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>DIS

SOAP odpovˇ ed na poˇ zadavek v protokolu HTTP HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn 1

Serializace je mechanismus pˇrevodu instanc´ı objekt˚ u do bin´ arn´ı podoby vhodné pro pˇrenos.


25

SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> 34.5

2.4.2

Model v´ ymˇ eny zpr´ av

ˇ Zprávy protokolu SOAP jsou v podstatˇe jednosmˇerné ve smˇeru od odes´ılatele k pˇr´ıjemci. Casto jsou ale implementovány podle návrhového vzoru Poˇzadavek/Odpovˇed. Samotné implementace tohoto protokolu mohou b´ yt optimalizovány pro konkrétn´ı charakteristiky komunikaˇcn´ıch s´ıt´ı. Tedy napˇr. pokud zprávu pos´ıláme v rámci poˇzadavku protokolu HTTP, odpovˇed pˇrijde stejn´ ym protokolem s pouˇzit´ım stejného spojen´ı. Nehledˇe na protokol, kter´ ym jsou tyto zprávy pˇren´ aˇseny, je moˇzné zprávy pˇrepos´ılat z jednoho pˇr´ıjemce k druhému s postupn´ ym zpracován´ım aˇz ke koneˇcnému pˇr´ıjemci. Aplikace, která pˇrij´ımá zprávy protokolu mus´ı provést následuj´ıc´ı operace v poˇrad´ı v jakém jsou napsány. 1. Identifikace vˇsech ˇcást´ı SOAP zprávy, urˇcen´ ych pro aplikaci 2. Ovˇeˇren´ı vˇsech povinn´ ych ˇcást´ı pˇredchoz´ıho bodu, které jsou podporovány aplikac´ı pro tuto zprávu a podle toho ji zpracovat. Jestliˇze tomu tak nen´ı, pak tuto zprávu ignorovat. Je moˇzné ignorovat nepovinné ˇcást´ı kroku 1 bez ovlivnˇen´ı v´ ysledku zpracován´ı 3. Pokud aplikace nen´ı posledn´ım pˇr´ıjemcem zprávy, odstran´ı pˇred pˇreposlán´ım vˇsechny ˇc´ asti identifikované v kroku 1. Jak uˇz jsem se zm´ınil protokol SOAP je aplikac´ı XML. Z tohoto d˚ uvodu by aplikace tohoto protokolu mˇela obsahovat pˇr´ısluˇsné jmenné prostory vˇsech element˚ u a atribut˚ u ve zpr´ av´ ach, které generuje. Rovnˇeˇz aplikace mus´ı b´ yt schopná tyto jmenné prostory zpracovat v pˇrijat´ ych zpráv´ ach. Pokud jmenn´ y prostor nen´ı korektn´ı mus´ı aplikace tyto zprávy zruˇsit. Zpr´ avy bez jmenného prostoru je moˇzné chápat jako zprávy s korektn´ım jmenn´ ym prostorem tohoto protokolu.


26

Protokol definuje následuj´ıc´ı dva jmenné prostory: SOAP Envelope – http://schemas.xmlsoap.org/soap/envelope/“ ” SOAP Serialization – http://schemas.xmlsoap.org/soap/encoding/“ ” Zprávy rovnˇeˇz nesm´ı obsahovat DTD a procesn´ı instrukce protokolu XML.

2.4.3

Envelope

SOAP zprávy se skládaj´ı z povinné ˇcásti SOAP Envelope, volitelné SOAP Header a povinné ˇcásti SOAP Body. Envelope je nejvyˇsˇs´ı element dokumentu reprezentuj´ıc´ı zprávu. Header je vˇseobecn´ y mechanismus pro pˇridáván´ı vlastnost´ı do zprávy v decentralizovaném chov´ an´ı bez pˇredchoz´ı domluvy komunikaˇcn´ıch stran. SOAP definuje nˇekolik málo atribut˚ u, které lze pouˇz´ıt k indikaci kdo má s danou vlastnost´ı pracovat a zda je volitelná nebo povinná. Body je pak kontejner pro povinné informace urˇcené koncovému pˇr´ıjemci zprávy. Standard definuje jeden element pro Body a to element Fault, kter´ y se pouˇz´ıvá pro pˇredáván´ı chyb. Pravidla pro vytv´ aˇ ren´ı zpr´ avy 1. Envelope jméno elementu je Envelope“ ” element mus´ı b´ yt souˇcást´ı zprávy element m˚ uˇze obsahovat deklaraci jmenn´ ych prostor˚ u právˇe tak jako dalˇs´ı atributy nebo podelementy. Pokud jsou tyto atributy nebo elementy pˇr´ıtomné, pak mus´ı b´ yt specifikované jménem jmenného prostoru a mus´ı b´ yt um´ıstˇené ze elementem Body 2. Header jméno elementu je Header“ ” element m˚ uˇze b´ yt souˇcást´ı zprávy. Pokud je souˇcást´ı, pak mus´ı b´ yt prvn´ım podelementem v elementu Envelope. element m˚ uˇze obsahovat mnoˇzinu podelement˚ u. Vˇsechny tyto podelementy mus´ı b´ yt rovnˇeˇz specifikované jménem jmenného prostoru. 3. Body jméno elementu je Body“ ” element mus´ı b´ yt souˇcást´ı zprávy a mus´ı b´ yt bud’ prvn´ım podelementem elementu Envelope, nebo mus´ı následovat bezprostˇrednˇe za podelementem Header, pokud je pˇr´ıtomen.


27

Obrázek 2.11: Struktura zprávy protokolu SOAP

Atribut encodingStyle Tento globáln´ı atribut je moˇzné pouˇz´ıt k indikaci serializaˇcn´ıch pravidel pouˇzit´ ych ve zpr´ avˇe. Pokud je v elementu tento atribut uveden, pak se vztahuje jen na obsah elementu a vˇsechny jeho podelementy. Standard nedefinuje implicitn´ı pravidlo. Hodnotou atributu je seznam jednoho nebo v´ıce URI definuj´ıc´ıch serializaˇcn´ı pravidla. Pravidla se uvádˇej´ı v poˇrad´ı od nejv´ıce specifického po nejménˇe. Standard definuje vlastn´ı serializaˇcn´ı pravidlo, které je definované v 5. kapitole standardu [1] a jeho URI je: http://schemas.xmlsoap.org/soap/encoding“. URI, které zaˇc´ınaj´ı t´ımto ˇretˇezcem ” pak indikuj´ı kompatibilitu s t´ımto pravidlem a poskytuj´ı jeho zpˇresnˇen´ı. Pokud bude hodnota atributu "", pak nebudou ˇzádné poˇzadavky na elementy. Podpora verz´ı Tento protokol nedefinuje tradiˇcn´ı model pro správu verz´ı zaloˇzen´ ych na hlavn´ıch a vedlejˇs´ıch ˇc´ıslech verz´ı. Zprávy m´ısto toho mus´ı obsahovat element, kter´ y je asociovan´ y se jmenn´ ym pros-


28

torem definovan´ ym t´ımto standardem ( http://schemas.xmlsoap.org/soap/envelope“). Pokud ” aplikace pˇrijme Envelope element s jin´ ym jmenn´ ym prostorem, mus´ı tuto zprávu zahodit a vrátit chybu verz´ı.

2.4.4

Header

Mechanismus hlaviˇcek umoˇzn ˇuje flexibilnˇe rozˇsiˇrovat zprávu o informace bez nutnosti pˇredchoz´ı znalosti komunikaˇcn´ıho partnera. Typick´ ym pˇr´ıkladem pro pouˇzit´ı hlaviˇcek je autentifikace a ˇr´ızen´ı transakc´ı. Header element je ve zprávˇe um´ıstˇen jako prvn´ı podelement v elementu Envelope. Pravidla pro poloˇzky hlaviˇcky jsou následuj´ıc´ı: 1. poloˇzka hlaviˇcky je identifikována pln´ ym jménem elementu, kter´ y se skládá z URI jmenného prostoru a lokáln´ıho jména. Vˇsechny podelementy pak mus´ı b´ yt rozliˇsitelné t´ımto jmenn´ ym prostorem. 2. atribut encodingStyle m˚ uˇze b´ yt pouˇzit pro indikaci pravidel pro serializaci na poloˇzku hlaviˇcky 3. atributy mustUnderstand a actor mohou b´ yt pouˇzité pro indikaci zp˚ usobu zpracov´ an´ı poloˇzky a k´ ym má b´ yt zpracována. Atributy hlaviˇcky urˇcuj´ı, jak se má pˇr´ıjemce zprávy zachovat. Aplikace, která pos´ılá zpr´ avu by mˇela pouˇz´ıvat atributy následuj´ıc´ıho podelementu elementu hlaviˇcky. Následnˇe pˇr´ıjemce zpr´ avy mus´ı ignorovat vˇsechny atributy, které nejsou k tomuto podlementu vztaˇzeny.

Uk´ azka hlaviˇ cky <SOAP-ENV:Header> ’’ ’’ 5


29

Atribut actor Bˇehem putován´ı zprávy od vys´ılatele k c´ılovému pˇr´ıjemci m˚ uˇze zpráva procházet r˚ uzn´ ymi meziaplikacemi, pˇriˇcemˇz tyto aplikace jsou zodpovˇedné za pˇreposlan´ı dalˇs´ımu pˇr´ıjemci. Soap zpr´ ava tak m˚ uˇze obsahovat ˇcásti, které nejsou urˇcené jen c´ılovému pˇr´ıjemci, ale mohou b´ yt jen pro nˇekteré aplikace na jej´ı cestˇe. Tento atribut slouˇz´ı k identifikaci pˇr´ıjemce zprávy. Identifikace je opˇet zaloˇzena na URI ˇretˇezci, a kaˇzd´ y pˇr´ıjemce mus´ı nastavit novou hlaviˇcku pˇred odeslán´ım zprávy. K identifikaci prvn´ıho pˇr´ıjemce slouˇz´ı ˇretˇezec http://schemas.xmlsoap.org/soap/actor/next“. Jestliˇze tento atribut ” chyb´ı, potom je pˇr´ıjemcem rovnou c´ılová aplikace. Atribut mustUnderstand Tento atribut indikuje, zda poloˇzka hlaviˇcky je povinná nebo volitelná z hlediska zpracov´ an´ı pˇr´ıjemcem. Pˇr´ıjemce je definov´ an atributem actor. Atribut m˚ uˇze nab´ yvat hodnot 1“ nebo ” 0“. Nepˇr´ıtomnost atributu je chápána jako hodnota 0“. ” ” Pokud je hodnota atributu 1“, pak se mus´ı pˇr´ıjemce poloˇzky bud’ podˇr´ıdit sémantice a zpracovat ” zprávu korektnˇe dle dané sémantiky nebo vyvolat chybu zpracován´ı. T´ım zajiˇst’ujeme robustnost zmˇen sémantiky, jelikoˇz nejsou ignorovány nesprávnˇe rozpoznané zprávy.

2.4.5

Body

Tento element slouˇz´ı k pˇredáván´ı povinn´ ych informac´ı c´ılovému pˇr´ıjemci zprávy. Nejˇcastˇejˇs´ım pouˇzit´ım elementu je vkládán´ı RPC volan´ ych metod a pˇredáván´ı chyb. Element mus´ı b´ yt bud’ prvn´ım podelementem elementu Envelope, nebo pokud element Envelope obsahuje element Header, pak mus´ı následovat hned za t´ımto podlementem. Vˇsechny poloˇzky elementu Body jsou chápány jako nezávislé. Standard definuje jednu poloˇzku Fault 2.4.6,která je urˇcena pro pˇrenos chyb. Pravidla pro poloˇzky jsou následuj´ıc´ı: 1. poloˇzka mus´ı b´ yt identifikována pln´ ym jménem, které se skládá z URI jmenného prostoru a vlastn´ıho jména. Podelementy mohou b´ yt identifikovány pln´ ym jménem. 2. atribut encodingStyle m˚ uˇze b´ yt pouˇzit´ y pro indikaci zp˚ usobu kódován´ı dané poloˇzky. Pˇrestoˇze elementy Header a Body jsou definovány jako nezávislé elementy, existuje mezi nimi vztah. Tento vztah je moˇzné chápat následovnˇe: Poloˇzka Body je ekvivalentn´ı poloˇzce elementu Header urˇcené pro defaultn´ıho pˇr´ıjemce s atributem mustUnderstand nastaven´ ym na hodnotu 1“. Defaultn´ı pˇr´ıjemce je indikován, ale nen´ı pouˇzit atribut actor. ”


2.4.6

30

Fault

Tento element se pouˇz´ıvá k pˇrenosu chyb a/nebo stavov´ ych informac´ı zprávy. Pokud je tento element pˇr´ıtomn´ y, pak mus´ı b´ yt um´ıstˇen v elementu Body. V celé zprávˇe m˚ uˇze b´ yt tento element jen jednou. Element definuje následuj´ıc´ı podelementy: faultcode — obsahuje ˇc´ıslo chyby, které je moˇzné pouˇz´ıt k vyhodnocen´ı chyby. Standard definuje nˇekolik základn´ıch k´ od˚ u pro protokol SOAP. Kódy chyby se generuj´ı podobnˇe jako v protokolu HTTP. Rozd´ılem je, ˇze jednotlivé ˇcásti kódu se oddˇeluj´ı teˇckou a jedn´ a se o textové ˇretˇezce (napˇr: Client.Authentication). Základn´ı kódy chyb jsou: VersionMismatch, MustUnderstand, Client a Server. Podrobnosti a v´ yznamy kód˚ u lze nalézt v [1] (kapitola 4.4.1). faultstring — obsahuje text chybové zprávy, kter´ y je moˇzné zobrazit uˇzivateli. Mus´ı b´ yt souˇcást´ı chybové zprávy a mˇel by vysvˇetlit o jakou chyby se jedná. faultactor — identifikuje kdo danou chybu vyvolal. Je podobn´ y atributu actor, ale narozd´ıl od nˇej indikuje zdroj chyby ve formˇe URI. Aplikace, která nen´ı c´ılov´ ym pˇr´ıjemcem mus´ı tento element vkládat do zprávy. C´ılová aplikace m˚ uˇze pouˇz´ıt tento element k explicitn´ı indikaci chyby v kombinaci s elementem detail. detail — je zodpovˇedn´ y za pˇrenos aplikaˇcn´ıch informac´ı o dané chybˇe vztahuj´ıc´ıch se k elementu Body. Mus´ı b´ yt souˇcást´ı zprávy tehdy pokud element Body nem˚ uˇze b´ yt u ´spˇeˇsnˇe zpracován. Detailn´ı informace o chybˇe v poloˇzce elementu Header mus´ı b´ yt pˇren´ aˇseny rovnˇeˇz v poloˇzkách elementu Header. Nepˇr´ıtomnost tohoto elementu lze vyuˇz´ıt pro rozliˇsen´ı, zda element má b´ yt nebo nem´ a b´ yt zpracováván v okamˇziku chyby.

2.4.7

SOAP v HTTP

I kdyˇz je moˇzné SOAP protokol pouˇz´ıt s r˚ uzn´ ymi protokoly, jeho nejˇcastˇejˇs´ı pouˇzit´ı je s protokolem HTTP a jeho metodou POST. Protokol nemˇen´ı sémantiku protokolu HTTP jen jej rozˇsiˇruje o svou. SOAP zachovává styl zpráv zaloˇzen´ ych na modelu poˇzadavek/odpovˇed, kdy SOAP poˇzadavek je odes´ılan jako HTTP poˇzadavek a naopak SOAP odpovˇed’ je zas´ıl´ ana jako HTTP odpovˇed’. Typ obsahu HTTP zprávy nesouc´ı SOAP zprávu mus´ı m´ıt hodnotu text/xml“ ” SOAP protokol rozˇsiˇruje hlaviˇcku HTTP poˇzadavku o pole SOAPAction, které m˚ uˇze identifikovat obsah a umoˇzn ˇuje tak r˚ uzn´ ym server˚ um nebo firewall˚ um pˇr´ısluˇsnˇe filtrovat HTTP zpr´ avy.


31

SOAP odpovˇed’ dodrˇzuje sémantiku HTTP stavov´ ych kód˚ u pro komunikaci, takˇze napˇr. pokud se pos´ılá zpˇet v´ ysledek správnˇe zpracované zprávy zas´ılá se kód 2xx. Naopak pokud doˇslo k chybˇe bˇehem zpracován´ı, mus´ı se zaslat kód 500 Internal Server Error“ a tˇelo SOAP zpr´ avy mus´ı ” obsahovat element Fault.

2.4.8

SOAP a RPC

Jednou z v´ yhod protokolu SOAP je jeho schopnost zapouzdˇrovat volán´ı RPC funkc´ı do jazyka XML. RPC volán´ı je moˇzné mapovat do HTTP poˇzadavku a odpovˇed’ na volán´ı RPC funkce pak do HTTP odpovˇedi. Protokol HTTP, ale nen´ı jedin´ y protokol a m˚ uˇze b´ yt pouˇzit´ y i jak´ ykoliv jin´ y protokol, kter´ y um´ı pˇrenáˇset zprávy protokolu SOAP. Pro volán´ı funkc´ı je nutné poskytnout následuj´ıc´ı informace: URI c´ılového objektu jméno metody volitelnˇe signaturu metody parametry metody volitelnˇe data v hlaviˇcce RPC volán´ı i odpovˇed jsou pˇren´ aˇseny v elementu Body a s pouˇzit´ım následuj´ıc´ı reprezentace: volán´ı metody je modelov´ ano jako struktura volán´ı metody je chápáno jako jednoduchá struktura obsahuj´ıc´ı elementy pro kaˇzd´ y vstupn´ı nebo vstupnˇe/v´ ystupn´ı parametr. Struktura je zároveˇ n pojmenována a otypována stejnˇe jako jméno metody. kaˇzd´ y vstupn´ı nebo vstupnˇe/v´ ystupn´ı parametr je zobrazován jako element s jménem a typem odpov´ıdaj´ıc´ı jménu a typu parametru. Vˇse ve stejném poˇrad´ı jako v signatuˇre metody. odpovˇed’ metody je modelována jako struktura odpovˇed je chápána jako jednoduchá struktura obsahuj´ıc´ı elementy s návratovou hodnotou pro kaˇzd´ y v´ ystupn´ı nebo vstupnˇe/v´ ystupn´ı parametr. Prvn´ı element obsahuje n´ avratovou hodnotu funkce a dalˇs´ı pak jednotlivé parametry ve stejném poˇrad´ı jako v signatuˇre typu.


32

Kaˇzd´ y element má stejné jméno a typ jako pˇr´ısluˇsn´ y parametr. Jméno návratové hodnoty nen´ı podstatné, stejnˇe tak jako jméno struktury. Pˇresto se doporuˇcuje dodrˇzovat konvenci, která pojmenovává strukturu jménem metody s pˇridan´ ym ˇretˇezcem Response“. ” pˇrenos chyby v metodˇe je pˇrenáˇsen pomoc´ı elementu Fault. Pokud pˇrenosov´ y protokol pˇridává dalˇs´ı pravidla pro identifikaci chyby, je nutné je rovnˇeˇz uvést. Chybˇej´ıc´ı parametry m˚ uˇze metoda bud’ zpracovat, nebo vrátit chyby.

3. JUMBO klient

3.1

Anal´ yza souˇ casn´ eho stavu

Jak jiˇz bylo uvedeno v pasáˇzi vˇenované systému JUMBO, jedná se o experimentáln´ı datab´ azi. Zat´ım existoval pouze server se kter´ ym bylo moˇzné pracovat pomoc´ı prohl´ıˇzeˇce HTML str´ anek. Toto ˇreˇsen´ı ale neposkytuje ve své podobˇe dostateˇcn´ y komfort pro práci uˇzivatele. Samotn´ y server je bohuˇzel stále nedokonˇcen´ y a nˇekteré funkce vznikaly soubˇeˇznˇe aˇz s touto diplomovou prac´ı a tak nebylo moˇzné je plnˇe otestovat.

3.2

Specifikace poˇ zadavk˚ u procházen´ı mezi objekty na serveru v rámci daného zobrazován´ı vytváˇren´ı instanc´ı objekt˚ u serveru editace a mazán´ı atribut˚ u a vztah˚ u volán´ı operac´ı nad objekty ˇreˇsen´ı cachován´ı objekt˚ u serveru na stranˇe klienta aplikaci implementovat tak, aby umoˇzn ˇovala v´ıce zp˚ usob˚ u zobrazen´ı objekt˚ u

3.3 3.3.1

Anal´ yza Gener´ ator formul´ aˇ r˚ u

Jedn´ım ze základn´ıch nedostatk˚ u nynˇejˇs´ı verze klienta je jeho uˇzivatelská nepˇr´ıvˇetivost v oblasti zobrazován´ı objekt˚ u. Aplikace by proto mˇela b´ yt v tomto ohledu variabiln´ı a je ji proto nutné navrhnout tak, aby umoˇzn ˇovala zobrazovat objekty r˚ uzn´ ymi zp˚ usoby. Tuto schopnost zajiˇst’uje Generátor formuláˇr˚ u“, kter´ y je moˇzné vidˇet na obrázku 3.1. Tento generátor poskytuje rozhran´ı ” pro samotné uˇzivatelské rozhran´ı, které na základˇe dat z generátoru a samotn´ ych dat aplikace nab´ıdne tento formuláˇr uˇzivateli.

3.3 Anal´ yza

34

Obr´ azek 3.1: Navrˇzené schéma aplikace

3.3.2

Komunikace se serverem

Dalˇs´ı poˇzadavek, kter´ y bylo nutné ˇreˇsit byla samotná komunikace mezi klientem a serverem. Tato komunikace je zajiˇst’ována komunikaˇcn´ım rozhran´ım. Toto rozhran´ı rozhoduje, zda se maj´ı pouˇz´ıt jiˇz lokálnˇe uloˇzené objekty, nebo se maj´ı tyto objekty naˇc´ıst z databáze. Rozhodnut´ı pouˇz´ıvat cachován´ı objekt˚ u na lokáln´ı stranˇe vycházelo z poˇzadavku, kter´ y pˇredpokl´ ad´ a, ˇze bˇehem procházen´ı daty se vˇetˇsina objekt˚ u nebude mˇenit. Toto pravidlo plat´ı hlavnˇe pro metadata jednotliv´ ych modul˚ u. Samotn´ y server pro potˇrebu cachován´ı poskytuje pro kaˇzd´ y objekt ˇcasové raz´ıtko, které informuje o ˇcase posledn´ı zmˇeny objektu. Na obrázku 2.4 je moˇzné vidˇet, ˇze tento klient bude vyuˇz´ıvat protokol SOAP. Server v rámci tohoto protokolu poskytuje n´ asleduj´ıc´ı metody. Pojmy attribute a parameter vycház´ı z pojmu protokolu SOAP, kdy atribut je ch´ ap´ an jako atribut elementu a parametr je chápán jako podelement elementu s metodou.

metoda getClass string name – jméno tˇr´ıdy ve formátu: modul$tˇr´ıda

3.3 Anal´ yza

35

Metoda vrát´ı tˇr´ıdu uloˇzenou v databázi na základˇe jej´ıho jména

metoda GetObject attribute long oid – oid objektu attribute string path – um´ıstˇen´ı objektu v databázi return object – data objektu

Metoda m˚ uˇze dostat jako parameter jeden ze dvou moˇzn´ ych. Nikdy ne oba zároveˇ n. Na z´ akladˇe daného parametru následnˇe vyhledá v databázi pˇr´ısluˇsn´ y objekt a vrát´ı ho.

metoda GetObjectHeader attribute long oid – oid objektu return object – hlaviˇcka objektu

Metoda vrát´ı pouze hlaviˇcku objektu skládaj´ıc´ı se z jeho jména, oid, typu a ˇcasového raz´ıtka

metoda DeleteObject attribute long oid – oid objektu

Metoda zajist´ı vymazán´ı objektu s dan´ ym oid z databáze.

metoda EditObject attribute long oid – oid objektu parameter object – zmˇenˇené atributy/vztahy objektu

Metoda zajist´ı zmˇenu hodnot daného objektu. Data jsou zas´ılány v podobˇe dvojice jména atributu/vztahu a jeho nové hodnoty jako podelementy parametru object. Pokud se mˇen´ı kolekce pak se zas´ılaj´ı pouze zmˇeny v r´ amci kolekce. Znak +“ znamená pˇridán´ı prvku do kolekce a ” znak -“ odstranˇen´ı následuj´ıc´ıho prvku z kolekce. ”

3.3 Anal´ yza

36

metoda CreateObject attribute string class – jméno tˇr´ıdy, kterou chceme instanciovat return long oid – oid novˇe vytvoˇrené instance daného objektu

Metoda vytvoˇr´ı novou instanci dané tˇr´ıdy. Jméno tˇr´ıdy se zadává v podobˇe modul$tˇr´ıda.

metoda InvokeMethod attribute string op – jméno operace, kterou chceme vykonat attribute long this – oid objektu, kter´ y danou operaci volá parameter parameters – parametry dané operace return result – v´ ysledek volán´ı operace Metoda zajiˇst’uje volán´ı operac´ı objekt˚ u v databázi. V´ ysledkem operace je následnˇe bud’ liter´ al, nebo oid objektu, kter´ y obsahuje v´ ysledek volané operace.

3.3.3

Cache

Jak jiˇz bylo zm´ınˇeno, objekty bude potˇreba na stranˇe klienta doˇcasnˇe ukládat. Algoritmus cachován´ı vycház´ı z moˇznost´ı serveru a kop´ıruje princip cachován´ı protokolu HTTP. Komunikaˇcn´ı manaˇzer nejprve otestuje existenci objektu v cache. Pokud tento objekt neexistuje, pak poˇz´ ad´ a server rovnou o cel´ y objekt. Pokud je tento objekt jiˇz v lokáln´ı cache, tak se ˇzádá po serveru jenom hlaviˇcka objektu. Následnˇe se porovnaj´ı ˇcasové raz´ıtka. Pokud je ˇcasové raz´ıtko ze serveru novˇejˇs´ı neˇz raz´ıtko objektu v cache, zajist´ı se opˇetovné naˇcten´ı objektu ze serveru.

3.3.4

Historie

V databázi mohou existovat objekty, které se skládaj´ı jen z atribut˚ u a tak nen´ı moˇzné z tohoto objektu pokraˇcovat na jin´ y objekt. Tato skuteˇcnost znamená, ˇze se nedostaneme ani na pˇredchoz´ı objekt, ze kterého jsme pˇriˇsli. Z tohoto d˚ uvodu je nutné v aplikaci implementovat historii procházen´ı, která tento nedostatek ˇreˇs´ı.

3.4 N´ avrh a implementace

3.4

37

N´ avrh a implementace

Pˇrestoˇze samotn´ y server je napsan´ y v jazyce C++, d´ıky protokolu SOAP mohla b´ yt implementace klienta vytvoˇrena v jazyce JAVA. Pro protokol SOAP byla zvolena implementace eSOAP firmy Embedding.Net, která je dostupná jak pro C++, tak i JAVu. Okno aplikace bylo rozdˇeleno na 2 d˚ uleˇzité ˇcásti. V horn´ı ˇcásti hned pod menu je panel s nab´ıdkou operac´ı, které lze v aplikaci provádˇet. Pod t´ımto panelem je plocha pro um´ıstˇen´ı formuláˇr˚ u daného generátoru. Klient dodrˇzuje zásady pro psan´ı v´ıcejazykov´ ych program˚ u a tak je moˇzné klienta pouˇz´ıvat ve v´ıce jazyc´ıch. Konkrétnˇe se jedná o ˇceˇstinu a angliˇctinu. Pro ostatn´ı jazyky lze vyuˇz´ıt nastaven´ı dle aktuáln´ıho jazyka systému. Uv´ ad´ım zde jenom nejd˚ uleˇzitˇejˇs´ı tˇr´ıdy rozhran´ı. Podrobn´ y popis vˇsech tˇr´ıd a metod lze nalézt na pˇriloˇzeném médiu, kde se nacház´ı i tato aplikace.

3.4.1

R´ amec aplikace

Celá aplikace je spojena pomoc´ı tˇr´ıdy MainFrame. Tato tˇr´ıda zajiˇst’uje propojen´ı mezi jednotliv´ ymi ˇcástmi aplikace a je odpovˇedná za rozm´ıstˇen´ı jednotliv´ ych grafick´ ych komponent v aplikaci. Jedná se o aplikaˇcn´ı menu, panel s operacemi nad objekty a stavov´ y ˇrádek. Dalˇs´ım u ´kolem této tˇr´ıdy je vytvoˇren´ı instance komunikaˇcn´ıho rozhran´ı a podpory pro logován´ı událost´ı v aplikaci. Následuj´ıc´ı diagram tˇr´ıd zobrazuje vazby mezi tˇr´ıdami aplikace. Tˇr´ıda MainMenu implementuje menu aplikace, které kromˇe nastaven´ı parametr˚ u poskytuje dva vstupn´ı body k objekt˚ um v databázi. Jedná se o seznam extent˚ u a seznam modul˚ u.

Obrázek 3.2: Diagram tˇr´ıd rámce aplikace

3.4.2

Gener´ ator formul´ aˇ r˚ u

V bal´ıˇcku edu.vsb.navrat.jumbo.gui lze nalézt dále uvedené tˇr´ıdy a rozhran´ı gener´ atoru.


38

Bˇehem implementace aplikace, bylo nutné ˇreˇsit problém návaznosti této diplomové pr´ ace a diplomové práce Ladislava Pavlici. Obsahem jeho diplomové práce je knihovna grafick´ ych uˇzivatelsk´ ych prvk˚ u. Pouˇzit´ım tˇechto prvk˚ u bude moˇzné vytváˇret pˇekné“ formuláˇre. Tyto prvky ” na základˇe typu jednotliv´ ych objekt˚ u a typu atribut˚ u budou volit vhodnou grafickou reprezentaci dat. Napˇr´ıklad pokud objekt bude obsahovat v´ yˇctov´ y typ o velikosti tˇr´ı moˇzn´ ych hodnot nab´ıdne skupinu pˇrep´ınaˇc˚ u, kdeˇzto pro v´ yˇctov´ y typ o vˇetˇs´ı velikosti nab´ıdne jiˇz seznam s povolen´ ym v´ ybˇerem jedné hodnoty. Generován´ı tˇechto formuláˇr˚ u následnˇe zajist´ı pˇr´ısluˇsné generátory. Na základˇe stavu rozpracovanosti jednotliv´ ych prac´ı byl implementován základn´ı generátor, kter´ y zobrazuje jak atributy, tak i vztahy objektu jako poloˇzky tabulky. Samotné operace objektu jsou pak zobrazov´ any pod touto tabulkou jako tlaˇc´ıtka. Jelikoˇz zat´ım neexistuje jiná implementace tohoto generátoru, nen´ı uˇzivateli nab´ıdnuta moˇznost interaktivnˇe si tyto generátory mˇenit. Pˇresto jiˇz s touto moˇznost´ı klient poˇc´ıtá a generátor je moˇzné nastavit editac´ı konfiguraˇcn´ıho souboru klienta.

interface GuiRenderer Tento interface popisuje rozhran´ı, které mus´ı jednotlivé implementace generátoru implementovat. Interface vznikl na základˇe implementace nynˇejˇs´ıho generátoru a je moˇzné, ˇze toto rozhran´ı se m´ırnˇe pozmˇen´ı v pˇr´ıpadˇe pokusu zaˇclenˇen´ı generátoru pouˇz´ıvaj´ıc´ıho knihovnu grafick´ ych prvk˚ u. Metody tohoto rozhran´ı vrac´ı jednak konkrétn´ı implementace dan´ ych akc´ı, které m˚ uˇze klient provádˇet a dále odkaz na konkrétn´ı panel s formuláˇrem. Základn´ı filozofie vycház´ı z principu, kdy jsou jednotlivé operace s objekty pˇrizp˚ usobené na m´ıru danému generátoru formul´ aˇre.

setMainFrame() getModulesAction() getExtentsAction() getBrowseAction() getPreviousButtonAction() getCreateButtonAction() getDeleteButtonAction()

nastav´ı odkaz na aplikaˇcn´ı rámec aplikace implementace akce zajist´ı naˇcten´ı extentu se seznamem vˇsech modul˚ u instalovan´ ych v databázi a jeho zobrazen´ı implementace akce zajist´ı naˇcten´ı seznamu vˇsech extent˚ u v databázi a zobraz´ı tento seznam implementace zajist´ı zobrazen´ı dalˇs´ıho poˇzadovaného objektu implementace zajist´ı pˇrechod na pˇredchoz´ı objekt v historii implementace zajist´ı vytvoˇren´ı nového objektu implementace zajist´ı smazán´ı zobrazeného objektu z databáze


39

Obr´ azek 3.3: Diagram tˇr´ıd generátoru

getEditButtonAction() getSaveButtonAction() getViewPanel

implementace zajist´ı pˇrepnut´ı do editaˇcn´ıho reˇzimu objektu, pˇr´ıpadnˇe jeho zruˇsen´ı implementace zajist´ı uloˇzen´ı zmˇenˇen´ ych hodnot zobrazeného objektu implementace vrát´ı aktuáln´ı instanci panelu se zobrazen´ ym objektem

class GuiRendererFactory Tato tˇr´ıda na základˇe nastaveného parametru (viz 3.4.8) aplikace vytvoˇr´ı instanci konkrétn´ıho generátoru formuláˇr˚ u. Instance je následnˇe pˇredána aplikaˇcn´ımu rámci. createJumboGuiRenderer()

instancializuje konkrétn´ı implementaci generátoru


40

class SimpleTableGuiRenderer Zat´ım jediná implementace generátoru formuláˇr˚ u vytvoˇr´ı a vrát´ı instanci této tˇr´ıdy

newInstance()

3.4.3

Gener´ ator formul´ aˇ r˚ u - SimpleTableGuiRenderer

Tato zat´ım jediná implementace generátoru obsahuje dvˇe základn´ı varianty zobrazen´ı. Prvn´ı varianta se pouˇz´ıvá pro zobrazen´ı strukturovaného typu Dictionary a je pouˇzita pro zobrazen´ı seznamu extent˚ u. Druhá varianta je následnˇe pouˇzita pro vˇsechny ostatn´ı objekty. Tyto dvˇe varianty ˇreˇsen´ı pˇredstavuj´ı tˇr´ıdy CollectionModel a AttributesModel.

Obrázek 3.4: Diagram tˇr´ıd model˚ u pro tˇr´ıdu JTable

interface Browsable U obou model˚ u bylo potˇrebné dozvˇedˇet se, kter´ y objekt je aktuáln´ı a kter´ y objekt chceme pˇr´ıpadnˇe dále zobrazit. Tuto vlastnost zajiˇst’uje implementace tohoto rozhran´ı. getActualOID() getBrowseToOID()

metoda vrát´ı oid objektu, na kterém se moment´ alnˇe nacház´ıme metoda vrát´ı oid objektu na kter´ y odkazuje vybran´ y ˇrádek tabulky


41

class AttributesModel Tˇr´ıda implementuje model tabulky a definuje vzhled této tabulky. Model je schopen rozhodnout na základˇe znalost´ı hodnoty atributu, zda má zobrazit jednoduch´ y ˇretˇezec nebo kombobox s v´ıce hodnotami. Model rovnˇeˇz podporuje editaˇcn´ı reˇzim. Editace primitivn´ıch typ˚ u se provád´ı pˇr´ımo v tabulce. Typy vycházej´ıc´ı z databázového typu Blob a veˇskeré reference a kolekce se n´ aslednˇe edituj´ı v jin´ ych dialoz´ıch a model zajiˇst’uje jen aktualizaci v´ ysledku editace.

class CollectionModel Druh´ y z model˚ u pro tabulku zobrazuj´ıc´ı objekty je urˇcen pro zobrazen´ı poloˇzek kolekce typu Dictionary. Tento model je urˇcen pouze pro zobrazen´ı dat a nepovoluje ˇzádnou editaci.

class ViewAttribute Tˇr´ıda je v´ ysledkem transformace atribut˚ u a vztah˚ u do grafick´ ych objekt˚ u. Uchovává informace o daném atributu nebo vztahu a tvoˇr´ı jeden ˇrádek v tabulce s modelem tˇr´ıdy AttributesModel. Instance této tˇr´ıdy si uchovávaj´ı informace o tom, zda byly modifikovány coˇz umoˇzn ˇuje ukl´ adat jen ty atributy, které se skuteˇcnˇe zmˇenily.

class ViewDictionary Tˇr´ıda uchovává informace o poloˇzce kolekce a tvoˇr´ı jeden ˇrádek v tabulce s modelem tˇr´ıdy CollectionModel.

class ViewListObject Instance této tˇr´ıdy mohou obsahovat libovoln´ y objekt a uchovávaj´ı si indikaci zda je dan´ y objekt vybran´ y. Vyuˇz´ıvá se jako poloˇzka kombobox˚ u v tabulce a v editaci kolekc´ı a referenc´ı.

BlobDialog Dialog poskytuje schopnosti editace objekt˚ u odvozen´ ych od typu Blob.


42

ListEditDialog Dialog umoˇzn ˇuje editovat u objektu vztahy a atributy, které jsou typu kolekce. Pokud je zn´ am pro typ poloˇzky extent, je obsah tohoto extentu uˇzivateli nab´ıdnut. V ostatn´ıch pˇr´ıpadech je moˇzné novou hodnotu vloˇzit pˇr´ım´ ym zadán´ım OID (v pˇr´ıpadˇe typ˚ u).

Obrázek 3.5: Diagram tˇr´ıd panel˚ u generátoru

class ObjectTableViewPanel Tˇr´ıda má na starost samotné zobrazen´ı poˇzadovaného objektu a rozm´ıstˇen´ı jednotliv´ ych panel˚ u. Po této inicializaci vzhledu se pak jiˇz stará o zmˇenu stavu nˇekter´ ych tlaˇc´ıtek pro práci s objekty.

class OperationsPanel Tˇr´ıda vytváˇr´ı v aplikaci panel obsahuj´ıc´ı tlaˇc´ıtka vˇsech operac´ı, které lze vykonat nad dan´ ym objektem. Instance této tˇr´ıdy je pˇriˇrazena promˇenné objectSpecificPanel ve v´ yˇse uvedené tˇr´ıdˇe.

class ParametersInputDialog Tˇr´ıda implementuje dialog pro zadáván´ı parametr˚ u operac´ı. Dialog zobrazuje vˇzdy zat´ım m´ısto skuteˇcného názvu parametru slovo param“ následuj´ıc´ı jeho poˇradov´ ym ˇc´ıslem. Je to zp˚ usobeno ” t´ım, ˇze server neuchovává po kompilaci metod tyto parametry, ale jen signaturu typ˚ u, ze které klient pro tento dialog generuje tyto parametry.


3.4.4

43

Akce klienta

Veˇskeré akce klienta jsou v bal´ıˇcku edu.vsb.navrat.jumbo.gui.action.

Obrázek 3.6: Diagram tˇr´ıd akc´ı

class ExtendedAction Tato abstraktn´ı tˇr´ıda je spoleˇcn´ ym pˇredkem vˇsech tˇr´ıd. Pro jednotlivé akce nastavuje aplikaˇcn´ı konstanty na základˇe aktuáln´ıho jazyka aplikace. Nastavuje se klávesová zkratka pro danou akci, jméno akce, znak pro pˇr´ıstup pˇres klávesu Alt a kontextová nápovˇeda pro akci. init()

metoda inicializuje konkrétn´ı konstanty

Akce rozhran´ı Jedná se o obecné akce, které nemaj´ı vztah k databázi. AboutAction ExitAction SettingAction

akce zobraz´ı informaˇcn´ı dialog o aplikaci akce ukonˇc´ı aplikaci a uloˇz´ı parametry aplikace do souboru akce zobraz´ı dialog pro nastaven´ı parametr˚ u aplikace


44

Datab´ azov´ e akce Tyto akce pracuj´ı s objekty databáze. Jedná se o podporu ˇctyˇr základn´ıch databázov´ ych operac´ı, o procházen´ı databáz´ı a volán´ı operace nad dan´ ym objektem. ExtentsAction ModulesAction BrowseButtonAction

CreateButtonAction DeleteButtonAction EditButtonAction PreviousButtonAction SaveButtonAction

3.4.5

akce zobraz´ı seznam se vˇsemi extenty databáze spoleˇcná implementace pro dalˇs´ı akce. Zajiˇst’uje naˇcten´ı objektu z databáze akce na základˇe reˇzimu práce zajist´ı pˇrechod na objekt na kter´ y ukazuje aktuáln´ı ˇrádek tabulky, nebo pokud je v editaˇcn´ım reˇzimu umoˇzn´ı editaci nˇekter´ ych atribut˚ u a vztah˚ u akce vytvoˇr´ı novou instanci právˇe zobrazeného objektu a pˇrejde na nˇej akce smaˇze z databáze právˇe zobrazen´ y objekt a pokus´ı se vr´ atit na pˇredchoz´ı objekt v historii akce zajiˇst’uje pˇrep´ınán´ı do editaˇcn´ıho reˇzimu objektu a jeho stornován´ı pokud zmˇeny nechceme uloˇzit akce umoˇzn ˇuje vrátit se v historii procházen´ı na pˇredchoz´ı zobrazen´ y objekt akce uloˇz´ı provedené zmˇeny v objektu do databáze

Historie

Obrázek 3.7: Tˇr´ıdn´ı diagram historie procházen´ı

class BrowseHistory Tato tˇr´ıda implementuje historii procházen´ı. Historie funguje na principu zásobn´ıku, kdy pˇri pˇrechodu na dalˇs´ı objekt je do historie vloˇzeno oid aktuáln´ıho objektu. Následnˇe pokud pˇrech´ az´ıme zpˇet je nejv´ yˇse uloˇzené oid pouˇzito a je z vrcholu odstranˇeno. Pokud historie na vrcholu obsahuje hodnotu oid odpov´ıdaj´ıc´ı seznamu vˇsech extent˚ u, pak je celá historie vymazána. Toto omezen´ı bylo dodáno z implementaˇcn´ıch d˚ uvod˚ u, kdy se nepodaˇrilo vyˇreˇsit pˇrep´ınán´ı model˚ u z reˇzimu zobrazen´ı objekt˚ u do reˇzimu zobrazen´ı extent˚ u.


3.4.6

45

Komunikaˇ cn´ı rozhran´ı

Komunikaˇcn´ı rozhran´ı zajiˇst’uje veˇskerou komunikaci se serverem. Komunikace se serverem je bezestavová, coˇz znamená, ˇze s kaˇzd´ ym poˇzadavkem se pˇripojujeme znovu k serveru a po obdrˇzen´ı odpovˇedi je toto spojen´ı ukonˇceno. Tˇr´ıdy tohoto rozhran´ı se nacházej´ı v bal´ıˇcku edu.vsb.navrat.jumbo.business. Klient pro svou práci nepotˇrebuje m´ıt objekty dle standardu ODMG. Tˇr´ıda AbstractMetaObject a z n´ı zdˇedˇené tˇr´ıdy tak slouˇz´ı pouze jako adaptér naˇcten´ ych dat protokolu SOAP. Tyto data je moˇzné pouze ˇc´ıst. Jejich modifikace prob´ıh´ a nezávisle na tˇechto objektech. Objekt se aktualizuje po editaci opˇetovn´ ym naˇcten´ım ze serveru.

Obrázek 3.8: Diagram tˇr´ıd komunikaˇcn´ıho rozhran´ı

interface Connectable Rozhran´ı umoˇzn ˇuje propagovat v rámci aplikace referenci na vytvoˇrené komunikaˇcn´ı rozhran´ı klienta.


46

class ConnectionManager Samotné komunikaˇcn´ı rozhran´ı. Tˇr´ıda vytváˇr´ı zprávy pro protokol SOAP a následnˇe zpracov´ av´ a odpovˇedi na tyto zprávy. setURL() getObject() getClass() createClass() editObject() deleteObject() invokeMethod()

metoda nastav´ı adresu, na které bˇeˇz´ı databázov´ y server vrát´ı naˇcten´ y objekt. Tento objekt se vrát´ı bud’ z lok´ aln´ı cache, nebo naˇcten´ y ze serveru vrát´ı naˇctenou tˇr´ıdu ze serveru, nebo z lokáln´ı cache vytvoˇr´ı novou instanci daného typu na serveru a vr´ at´ı jej´ı oid uloˇz´ı provedené zmˇeny v objektu na server volá metodu pro smazán´ı objektu z databáze zajiˇst’uje spuˇstˇen´ı metody objektu ve virtuáln´ım stroji JiveVM na serveru. Po vykonán´ı operace vrac´ı jej´ı v´ ysledek

class AbstractMetaObject Tato abstraktn´ı tˇr´ıda implementuje spoleˇcné metody dvou následuj´ıc´ıch tˇr´ıd. getOID() getType() getLabel() getClassNameFromType()

vrát´ı oid objektu pod kter´ ym je v databázi uloˇzeno vrát´ı typ objektu ve formátu vhodném pro zobrazen´ı vrát´ı jméno objektu. vrát´ı plné jméno tˇr´ıdy ve tvaru <modul>$. Tento formát se pouˇz´ıvá pˇri komunikaci se serverem.

class MetaObject Tˇr´ıda uchovává naˇcten´ y objekt z protokolu SOAP, kter´ y obaluje sv´ ymi metodami. Objekt je nejprve pˇredzpracován, kdy se jednotlivé atributy, vztahy a typy atribut˚ u uloˇz´ı z p˚ uvodn´ı struktury do slovn´ıku parametr˚ u. Hodnoty jednotliv´ ych atribut˚ u, vztah˚ u a typu atribut˚ u jsou n´ aslednˇe zpracovány z tˇechto parametr˚ u aˇz pˇri poˇzadavku na dan´ y atribut, vztah ˇci typ atributu. Kolekce a vztahy jsou vráceny jako seznam hodnot a binárn´ı data jsou zpˇetnˇe dekódovány z form´ atu BASE64 do ˇcitelné podoby. Obdobnˇe pokud je atribut typu Type je ze signatury pˇreveden zpˇet do textové podoby.


47

Vyhled´ av´ an´ı typ˚ u – objekty v databázi jsou uloˇzené ve stromové struktuˇre. Pˇri hled´ an´ı typu atributu je nutné velmi ˇcasto tento strom procházet. Typ atributu se nejprve vyhledáv´ a pˇr´ımo v aktuáln´ım objektu a dále ve vˇsech objektech, které jsou k objektu ve vztahu properties“. ” Pokud nebyl ˇzádn´ y takov´ y objekt nalezen pokraˇcuje se v metaobjektu. Zde se cel´ a situace opakuje aˇz do okamˇziku, kdy se typ Class ptá sám sebe na typ nˇekterého atributu. Pokud jej nezná, vyhledáván´ı pokraˇcuje z p˚ uvodn´ıho objektu pˇres objekty, které jsou k objektu ve vztahu extender“. Obrázek 3.9 zobrazuje nejhorˇs´ı variantu vyhledáván´ı. ” Naˇ cten´ı operac´ı – Podobnˇe jako u hledán´ı typu pro konkrétn´ı atribut se postupuje pˇri naˇc´ıtán´ı seznamu operac´ı, které lze nad objektem spustit. Naˇc´ıtaj´ı se nejprve vˇsechny operace metatˇr´ıdy pro dan´ y objekt (objekty ve vztahu operations“) a následnˇe rekurzivnˇe vˇsechny ” operace objekt˚ u ze kter´ ych metatˇr´ıda dˇed´ı (vztah extender“). ”

Obrázek 3.9: Hledán´ı typu atributu nebo vztahu


initCaching() getAttributeNames() getAttribute() getRelationshipsNames() getRelationship() getType()

getOperations()

getModuleName() getMetaClassObject() isMetaClass()

48

metoda pˇrevede parametry ze seznamu do struktury slovn´ıku metoda vrát´ı seznam jmen vˇsech atribut˚ u metoda vrát´ı hodnotu atributu. metoda vrát´ı seznam jmen vˇsech vztah˚ u metoda vrát´ı seznam objekt˚ u se kter´ ymi je objekt v tomto vztahu veˇrejnˇe viditelná verze metody spouˇst´ı proces vyhled´ av´ an´ı typu. Samotné vyhledáván´ı prob´ıhá v neveˇrejné variantˇe této metody veˇrejnˇe viditelná verze metody spouˇst´ı proces z´ısk´ an´ı seznamu operac´ı nad objektem. Naˇc´ıtán´ı samotn´ ych operac´ı prob´ıhá v neveˇrejné variantˇe této metody. metoda vrát´ı modul ve kterém byl objekt definov´ an metoda naˇcte objekt, kter´ y reprezentuje metatˇr´ıdu objektu zajiˇst’uje konec vyhledáván´ı typu v okamˇziku, kdy je objekt totoˇzn´ y s objektem reprezentuj´ıc´ı typ Class v systémovém modulu ODLMetaObjects

class MetaObjectDictionary Tato tˇr´ıda reprezentuje strukturovan´ y typ Dictionary. Vnitˇrn´ı implementace je podobn´ a jako u pˇredchoz´ı tˇr´ıdy. Rozd´ıl je pouze v názvech metod a parametr˚ u. initCaching() getAssociateKeyNames() getAssociateValues()

metoda vytvoˇr´ı ze seznamu parametr˚ u opˇet jejich slovn´ık vrát´ı seznam vˇsech kl´ıˇc˚ u slovn´ıku vrát´ı hodnotu pro dan´ y kl´ıˇc

class JumboTypesResolver V databázi jsou typy jednotliv´ ych objekt˚ u a atribut˚ u uloˇzené jen jako signatury. Bˇeˇznému uˇzivateli ale nic neˇrekne, ˇze napˇr. vztah typu {SLODLMetaObjects$Property je vlastnˇe kolekce typu Set, jej´ıˇz poloˇzky jsou reference na typ Property definovaném v modulu ODLMetaObjects. Proto je nutné tuto signaturu pˇrevést zpˇet do p˚ uvodn´ıho popisu. Tuto funkci zajiˇst’uje tato tˇr´ıda. typeResolver()

pˇrekládá signaturu typu na jej´ı textov´ y popis


3.4.7

49

Cache

Komunikace po s´ıt´ı je vˇetˇsinou ˇcasovˇe nároˇcná. U protokolu SOAP je nutné nav´ıc pˇripoˇc´ıtat ˇcas potˇrebn´ y na reˇzii zpracován´ı dat, jelikoˇz dan´ı za platformovou nezávislost protokolu je velké mnoˇzstv´ı reˇzijn´ıch dat ve zprávˇe. Algoritmus ukládán´ı dat u klienta popsan´ y v anal´ yze je implementován tˇr´ıdou ConnectionManager. Následuj´ıc´ı obrázek zobrazuje graficky tento algoritmus.

Obrázek 3.10: Algoritmus cachován´ı objekt˚ u

class ObjectDatabaseCache a class ObjectDatabaseCache.CacheElement Tˇr´ıda funguje jako u ´loˇziˇstˇe naˇcten´ ych objekt˚ u ze serveru. Umoˇzn ˇuje vyhledávat objekty podle jejich oid a nebo podle jména objektu. Tato schopnost je zajiˇstˇena dvˇemi slovn´ıky, které si uchovávaj´ı jako hodnotu odkaz na stejnou poloˇzku cache. Vnitˇrn´ı tˇr´ıda CacheElement pˇredstavuje poloˇzku v cache. Tato poloˇzka si uchovává kromˇe objektu taky jeho oid, jméno a timestamp. Uloˇzen´ı obou kl´ıˇc˚ u v poloˇzce je nutné v okamˇziku mazán´ı kl´ıˇce.


3.4.8

50

Nastaven´ı aplikace

Klient umoˇzn ˇuje uˇzivateli nastavovat nˇekolik vlastnost´ı. Tyto vlastnosti se ukládaj´ı do konfiguraˇcn´ıho souboru, kter´ y je hledán v adresáˇri definovaném promˇennou JUMBO_HOME. Pokud je zde nenalezne, pak se pokus´ı jej vyhledat v domovském adresáˇri uˇzivatele. Soubor obsahuje n´ıˇze uvedené parametry. Hodnoty tˇechto parametr˚ u v pˇr´ıpadˇe, ˇze nen´ı nalezen soubor lze naj´ıt na pˇriloˇzen´ım CD v popisu tˇr´ıdy MainProperties. edu.vsb.navrat.jumbo.gui.MainFrame.host adresa stroje (vˇcetnˇe identifikace http://), kde bˇeˇz´ı server edu.vsb.navrat.jumbo.gui.MainFrame.port port na kterém bˇeˇz´ı server edu.vsb.navrat.jumbo.gui.MainFrame.router název routeru pro RPC komunikaci protokolu SOAP. Nezadáv´ a se interaktivnˇe v aplikaci. edu.vsb.navrat.jumbo.gui.MainFrame.localeID poˇradové ˇc´ıslo jazyka prostˇred´ı. 0 - systémov´ y jazyk, 1 - ˇcesky, 2 - anglicky edu.vsb.navrat.jumbo.gui.MainFrame.ui Tˇr´ıda nastavuj´ıc´ı vzhled prostˇred´ı aplikace (Look & Feel) edu.vsb.navrat.jumbo.gui.GuiRendererFactory.renderer Konkrétn´ı implementace generátoru formuláˇr˚ u. Nezadává se interaktivnˇe v aplikaci. class MainProperties Tˇr´ıda zajiˇst’uje podporu pro práci s parametry aplikace. Zajiˇst’uje jejich naˇcten´ı po startu aplikace, jejich uloˇzen´ı pˇri ukonˇcen´ı aplikace a jejich zmˇeny bˇehem práce.

class SettingDialog Dialog pro nastaven´ı nˇekter´ ych parametr˚ u aplikace. Jedná se o adresu stroje, vzhled klienta a pouˇzit´ y jazyk klienta.

3.4.9

Podp˚ urn´ e tˇ r´ıdy

Tˇr´ıdy popsané v této ˇcásti lze nalézt v bal´ıˇcku edu.vsb.navrat.jumbo. Jedná se o pomocné tˇr´ıdy zajiˇst’uj´ıc´ı logován´ı událost´ı a v´ıcejazykovost aplikace.


51

interface Logable Interface umoˇzn ˇuje tˇr´ıdám, které ho implementuj´ı propagovat odkaz na tˇr´ıdu zajiˇst’uj´ıc´ı logov´ an´ı událost´ı a chyb v systému.

class SystemLogger Tˇr´ıda, která zajiˇst’uje zápis ud´ alost´ı v aplikaci do souboru. Události se zapisuj´ı do souboru jumbo_client.log. Kromˇe toho aplikace rovnˇeˇz pˇresmˇerovává do souboru standardn´ı v´ ystup a standardn´ı chybov´ y v´ ystup. Tyto soubory maj´ı pˇr´ıponu out a err.

ResourceManager Tˇr´ıda spravuje ˇretˇezcové zdroje pouˇzité v aplikaci a poskytuje podporu pro v´ıcejazykovost klienta.

4. Z´ avˇ er

4.1

Zhodnocen´ı

C´ılem práce bylo vytvoˇren´ı nového uˇzivatelského klienta pro objektov´ y systém Jumbo. Bˇehem tvorby této aplikace jsem se sezn´ amil s technologiemi, které maj´ı velkou ˇsanci v budoucnu ovlivnit informaˇcn´ı technologie. Objektové databázové systémy v nejbliˇzˇs´ıch letech sice nedobudou pˇrevahy na trhu s databázov´ ymi technologiemi, ale pokud se podaˇr´ı zvládnout nev´ yhody tˇechto systém˚ u mohou velice dobˇre konkurovat dneˇsn´ım systém˚ um. Narozd´ıl od tˇechto systém˚ u se protokol SOAP jiˇz zaˇc´ıná vyskytovat na internetu a intranetu mnohem v´ıce. Nejˇcastˇeji se o nˇem mluv´ı ve spojitosti s webov´ ymi sluˇzbami. Do jaké m´ıry bude tato oblast u ´spˇeˇsná ukáˇze ˇcas. Velice kladnˇe hodnot´ım spolupráci s vedouc´ım diplomové práce, kter´ y je autorem systému ˇ Jumbo. Nesm´ım zapomenout ani na Petra Sulu a Ladislava Pavlicu, jejichˇz diplomové pr´ ace se také t´ ykaly systému Jumbo.

4.2

Dalˇ s´ı v´ yvoj

Aplikace v nynˇejˇs´ı verzi se podobá trochu své starˇs´ı pˇredch˚ udkyni. Aby tato aplikace byla uˇzivatelsky pˇr´ıtulná“ bude nutné vytvoˇrit pro tohoto klienta dalˇs´ı generátor formuláˇr˚ u, kter´ y jiˇz ” bude pouˇz´ıvat v´ ysledek diplomové práce Ladislava Pavlici. Do oblasti u ´prav stavaj´ıc´ıho ˇreˇsen´ı je moˇzné zahrnout zmˇenu form´ atu zas´ılan´ ych dat. Jedná se hlavnˇe o kolekce, které se zat´ım pos´ılaj´ı v protokolu SOAP jako jeden ˇretˇezec oddˇelen´ y mezerami. Pro tyto kolekce je logiˇctˇejˇs´ı pouˇz´ıt typ SOAP-ENC:Array. Bylo by vhodné upravit databázové schéma systému Jumbo tak, aby uˇzivatel pˇri volbˇe parametr˚ u operac´ı vidˇel skuteˇcné názvy tˇechto parametr˚ u a ne jen slovo jméno param0 pro prvn´ı parametr. Rovnˇeˇz bylo by vhodné vyˇreˇsit podporu pro OQL. V nynˇejˇs´ı podobˇe lze nab´ıdnout uˇzivateli v nab´ıdkách pouze objekty, které jsou v extentu. Do oblasti velk´ ych zmˇen je moˇzné zaˇradit pouˇz´ıván´ı rozhran´ı Reflection v Javˇe. Pouˇzit´ım tohoto rozhran´ı bychom mohli reprezentovat aplikaˇcn´ı typy pˇr´ımo jako tˇr´ıdy. To znamená, ˇze napˇr. pˇri poˇzadavku na hodnotu atributu adresa bychom nepouˇzili volán´ı getAttribute("adresa"), ale pˇr´ımo volán´ı getAdresa().

Literatura [1] Box Don et al. SOAP: Simple Object Access Protocol. World Wide Web Consortium, 2000. http://www.w3.org/TR/SOAP/. [2] Cattel R.G.G. et al. The Object Data Standard: ODMG 3.0. Morgan Kaufmann, San Francisco, 1999. ISBN 1-55860-647-4. ˇ - Technical [3] Beneˇs M. Data types in persistent object systems. In: Transaction of the VSB Univerzity, Vol I.(1/2001): str. 4–10, 2001. ˇ – Technick´ [4] Beneˇs M. Databázové a informaˇcn´ı systémy 3. [ sylaby k pˇrednáˇskám ], VSB a Univerzita Ostrava, 2001.

A. Uˇ zivatelsk´ a pˇ r´ıruˇ cka

A.1

Poˇ zadavky na syst´ em

Aplikace pro sv˚ uj bˇeh potˇrebuje m´ıt nainstalován Java Runtime Environment ve verzi 1.3 a vyˇsˇs´ı. Dalˇs´ı poˇzadavky na systém vypl´ yvaj´ı z podm´ınek pro provoz tohoto prostˇred´ı.

A.2

Instalace a spuˇ stˇ en´ı

Klienta nen´ı potˇreba sloˇzitˇe instalovat. Staˇc´ı rozbalit soubor jumbo-client.zip do libovolného adresáˇre a na tento adresáˇr nastavit systémovou promˇennou JUMBO_HOME. Klient se n´ aslednˇe spouˇst´ı dávkou client.bat (resp. client.sh v Linuxu).

A.3

Nastaven´ı aplikace

Po spuˇstˇen´ı je potˇreba nastavit adresu stroje na kterém bˇeˇz´ı server. Toto nastaven´ı lze provést v dialogu kter´ y se nacház´ı pod volbou Nastaven´ı v menu Soubor. Dialog m˚ uˇzete vidˇet na obr´ azku A.1. V tomto dialogu si m˚ uˇzete rovnˇeˇz nastavit vzhled klienta a jazyk, kter´ ym bude komunikovat. Zmˇena jazyka se projev´ı aˇz po novém spuˇstˇen´ı aplikace.

A.4

Pr´ ace s datab´ az´ı

Po spuˇstˇen´ı klienta je viditelná pouze ˇc´ıstá pracovn´ı plocha. Práci s databáz´ı lze zaˇc´ıt jedn´ım ze dvou vstupn´ıch bod˚ u. Oba body jsou v menu Datab´ aze. Volbou Extenty se dostaneme na seznam vˇsech extent˚ u v databázi. Volba Moduly následnˇe zobraz´ı extent, kter´ y obsahuje seznam se vˇsemi instalovan´ ymi moduly.

A.4.1

Proch´ azen´ı mezi objekty

Na obrázku A.2 je vidˇet, ˇze objekty jsou zobrazeny v tabulce. Pokud nˇekter´ y atribut nab´ yv´ a v´ıce hodnot, nebo se jedná o vztah jsou hodnoty zobrazeny pomoc´ı komboboxu. Vidˇet je pouze

A.4 Pr´ ace s datab´ az´ı

55

Obrázek A.1: Dialog nastaven´ı

Obrázek A.2: Zobrazen´ y objekt

aktuáln´ı hodnota na kterou je moˇzné pˇrej´ıt. Zmˇena této hodnoty se provád´ı v´ ybˇerem v tomto komboboxu. Pro pˇrechod se následnˇe pouˇzije tlaˇc´ıtka Pˇrej´ıt na . Pokud se chceme z objektu vrátit na pˇredchoz´ı objekt, m˚ uˇzeme k tomu pouˇz´ıt tlaˇc´ıtko Pˇrej´ıt zpˇet .

A.4.2

Vytv´ aˇ ren´ı objekt˚ u

Pod nab´ıdkou tlaˇc´ıtek s operac´ı se nacház´ı popis aktuálnˇe zobrazeného objektu. Je zde zobrazeno oid objektu, jeho jméno (pokud nˇejaké má) a typ. Pokud je objekt typu ODLMetaObjects::Class, lze vytvoˇrit novou instanci tohoto objektu. To provedeme tlaˇc´ıtkem Vytvoˇrit . Novˇe vytvoˇren´ a instance se následnˇe zobraz´ı.


A.4.3

56

Editace objekt˚ u

Bˇehem editace se ˇcásteˇcnˇe mˇen´ı funkce tlaˇc´ıtka Pˇrej´ıt na . Jeho pouˇzit´ı neprovede pˇrechod na následuj´ıc´ı objekt, ale umoˇzn´ı editovat atributy vycházej´ıc´ı z typu Blob, atributy typu kolekce a v neposledn´ı ˇradˇe vztahy. Do reˇzimu editace je moˇzné se pˇrepnout tlaˇc´ıtkem Editovat . Stejné tlaˇc´ıtko pak slouˇz´ı i pro zruˇsen´ı editace bez uloˇzen´ı zmˇen. Provedené zmˇeny je moˇzné uloˇzit tlaˇc´ıtkem Uloˇzit . Pokud by jsme se chtˇeli v reˇzimu editace vrát´ıt na pˇredchoz´ı objekt a jiˇz jsme provedli v aktuáln´ım objektu zmˇeny, pak je zobrazen potvrzovac´ı dialog. Editace atribut˚ u, které jsou primitivn´ıch typ˚ u je moˇzné provádˇet pˇr´ımo v tabulce kliknut´ım na hodnotu pˇr´ısluˇsného atributu. V následuj´ıc´ıch odstavc´ıch je popsána editace jin´ ych typ˚ u. Editace binarn´ıch textov´ ych dat Editace tˇechto dat se provád´ı v dialogu, kter´ y je moˇzné vidˇet na obrázku A.3. V tomto dialogu je moˇzné vytvoˇrit nov´ y Blob objekt, upravovat existuj´ıc´ı, pˇr´ıpadnˇe tento objekt vymazat z databáze. Pro usnadnˇen´ı editace je moˇzné do pracovn´ı plochy nahrát obsah souboru.

Obrázek A.3: Dialog pro editaci objektu typu Blob

Editace kolekc´ı a vztah˚ u Jak pro atributy typu kolekce, tak i pro vztahy se pouˇz´ıvá totoˇzn´ y dialog. Tento dialog je moˇzné vidˇet na obrázku A.4. Dialog se skládá ze dvou seznam˚ u, v levém seznamu jsou vidˇet aktu´ alnˇe vybrané hodnoty kolekce a vpravo jsou hodnoty, které lze vloˇzit do kolekce. Pokud zde nˇejak´ a hodnota chyb´ı, m˚ uˇzeme ji zadat v poli nad seznamem vybran´ ych hodnot. Pokud editujeme kolekci obsahuj´ıc´ı referenci, pak zadáváme oid objektu. V opaˇcném pˇr´ıpadˇe pˇr´ımo hodnotu, kterou chceme vloˇzit do seznamu. Pokud typ poloˇzky kolekce obsahuje v databázi extent, jsou hodnoty tohoho extentu nab´ıdnuty v pravém seznamu. Mezi tˇemito dvˇemi seznamy se nacház´ı panel s tlaˇc´ıtky pro pˇresun poloˇzek tˇechto seznam˚ u mezi sebou. Tyto pˇresuny jsou hl´ıdány z pohledu typu kolekce, takˇze nen´ı moˇzné vloˇzit do kolekce typu Set dvakrát stejn´ y objekt. Rovnˇeˇz pokud se jedná jen o vztah nen´ı moˇzné, aby vybran´ ych hodnotách bylo v´ıce neˇz jedna poloˇzka.


57

Obrázek A.4: Dialog pro editaci kolekc´ı a vztah˚ u

A.4.4

Vol´ an´ı operac´ı

Panel pod tabulkou je vyhrazen pro tlaˇc´ıtka jednotliv´ ych operac´ı, které lze nad objektem provádˇet. Pokud operace potˇrebuje zadat parametry, je zobrazen dialog, kter´ y toto zad´ an´ı umoˇzn ˇuje. Pokud nˇekter´ y z paramter˚ u je typu maj´ıc´ı v databázi extent, jsou hodnoty tohoto extenu nab´ıdnuty parametru. V opaˇcném pˇr´ıpadˇe je moˇzné zadat pˇr´ımo oid objektu. Po tomto zadán´ı je operace spuˇstˇena. Pokud operace vrac´ı referenci na objekt databáze, je tento objekt rovnou zobrazen. V ostatn´ıch pˇr´ıpadech je zobrazena zpráva s v´ ysledkem volán´ı operace. Dialog pro zadaván´ı parametr˚ u je moˇzné vidˇet na obrázku A.5.

Obrázek A.5: Dialog pro zadáván´ı parametr˚ u operac´ı

A.4.5

Maz´ an´ı objekt˚ u

Objekty je moˇzné z databáze vymazat tlaˇc´ıtkem Smazat . Pˇred smazán´ım je provedena jeˇstˇe kontroln´ı otázka. Zat´ım neexistuj´ı pro mazán´ı ˇzádné pravidla (a to ani na serveru). Proto pˇri mazán´ı bud’te velmi opatrn´ı.

B. Obsah CD

Adres´ aˇr

Popis

/jumbo-client.zip /Ant/ /Java/ /Jumbo_server/

Zabalená binárn´ı verze klienta Obdoba utility make pro kompilaci Instalaˇcn´ı soubory Java2 SDK v 1.2 Aktuáln´ı verze systému JUMBO. Spouˇst´ı se dávkou runserver.bat v adresáˇri db

/Jumbo/src /Jumbo/doc/api /Jumbo/doc/dipl-tex

Zdrojové soubory aplikace Popis tˇr´ıd pomoc´ı JAVADoc Texty diplomové práce

VŠB Technická univerzita Ostrava Fakulta elektrotechniky a informatiky Katedra informatiky

Recommend Documents