Michal Krátký
Katedra informatiky
VŠB - Technická univerzita Ostrava
tř. 17. listopadu
708 33 Ostrava - Poruba
E - mail: michal.kratky@vsb.cz
With development of computer networks grows need using technologies such as distributed applications and World Wide Web (WWW). Need of data visualization at WWW is apparent for Geographic Information System (GIS) too. The Article presents design and creating of distributed system based on CORBA technology, enable established dynamic into system. This system is suitable to storage of spatial data, their visualization at WWW and to incorporation measuring and controlling elements.
S rozvojem počítačových sítí roste potřeba použití technologií jako jsou distribuované aplikace a World Wide Web (WWW). Potřeba vizualizovat data na WWW je patrná i v oblasti geografických informačních systémů (GIS). Článek prezentuje návrh a vytvoření distribuovaného systému založeného na technologii CORBA, která umožňuje zavést do systému dynamiku. Tento systém je vhodný pro uložení prostorových dat, jejich vizualizaci na WWW a začlenění měřících a řídících prvků.
V tomto článku je prezentována diplomová práce ([6]), kterou autor vytvořil v rámci svého magisterského studia na Katedře informatiky VŠB-TU Ostrava. Diplomová práce byla obhájena 5.6.2001.
S rozmachem Internetu se stále více nabízí možnost zveřejňovat libovolné informace na tomto médiu. Jednou z takovýchto informací mohou být i prostorová data. Prostorová data jsou informace o prostorových prvcích. Prostorové prvky mají prostorové (např. geometrický tvar okresu) i neprostorové vlastnosti (např. počet obyvatel okresu). Je zřejmé, že vzhledem k možnému objemu takovýchto dat, si jejich uchování žádá značné hardwarové a softwarové požadavky na straně serveru. Více informací o prostorových datech a GIS obecně je uvedeno například v [15].
Data je potřeba uchovávat v databázi, ke které přistupuje softwarová vrstva, která předává požadovaná data ve vhodném formátu klientovi. Architektura systému vhodného pro uložení a vizualizaci dat na WWW se tedy přirozeně dělí na komponenty. Pokud bude takovýto systém vhodně navržen, bude snadné do něj vkládat další komponenty vhodně rozšiřující chování systému. Příkladem tohoto rozšíření může být např. přidání měřících a řídících komponent a vizualizace hodnot těchto měřících členů. Měřící prvek v systému pro práci s prostorovými daty můžeme chápat jako prostorový prvek s nějakým atributem, jehož hodnota je proměnná v čase.
Jelikož se, jak již bylo řečeno, dělí tento systém do komponent, přímo se nabízí využití některého z prostředí pro tvorbu distribuovaných aplikací. Je vhodné použít takovou technologii, která je dobře specifikována a není pouhým proprietárním řešením vázaným na operační systém popř. hardwarovou platformu. Takovouto technologií je bezpochyby CORBA (specifikace popsána v [7]).
V následujících kapitolách bude popsán navržený systém. V kapitole 2 bude popsána architektura systému a budou zdůvodněna některá zvolená řešení. V následujících kapitolách (kapitola 3 až kapitola 5) budou popsány některé komponenty systému.
Cílem bylo vypracovat obecnou distribuovanou architekturu systému vhodnou pro uložení a vizualizaci prostorových dat v prostředí CORBA a její integrace do WWW prostředí. Systém je navržen tak, aby byl vhodný nejen pro uložení a vizualizaci prostorových dat statických, ale i pro uložení a vizualizaci prostorových prvků jejichž nějaký atribut je v čase proměnný.
Nejprve bude na praktickém příkladě vysvětleno, co by měl takový systém vykonávat. Příklad je demonstrován na řekách a jejich stavech. Mějme tedy v databázi uloženy řeky České republiky. Dále mějme sondy měřící stav (hloubku) vody na několika místech libovolné řeky. Uživateli se po zadání daného URL ve WWW prohlížeči spustí aplikace, která mu umožní prohlížet si statická (řeky) i dynamická (aktuální stavy vod) prostorová data. Výběrem vrstvy řek a sond stavu vod na řekách se uživateli zobrazí vrstva řek a v pravidelných intervalech i aktuální hodnoty sond. Dále může být spuštěn nějaký akční člen, který bude např. hlídat, zda sonda na řece Moravě v Olomouci nepřekročila hodnotu 4 m. Pokud ano, dojde k vykonání nějaké akce.
Po konkrétním příkladu použití budou vysvětleny pojmy distribuovaná aplikace, distribuovaná objektová aplikace, CORBA a ORB. Distribuovaná aplikace je aplikace, která neběží pouze na jednom počítači, ale je rozložena na více počítačích v síti. S nástupem objektově-orientovaných technologií se objevuje i pojem distribuovaná objektová aplikace, což je aplikace skládající se z komponent (objektů), z nichž každá může běžet na jiném počítači v síti. Object Request Broker (ORB) je softwarová vrstva, která umožňuje volat stejným způsobem metody lokálních i vzdálených objektů. Common Object Request Broker Architecture (CORBA) je specifikace vydaná organizací OMG v [7], která definuje architekturu abstraktního ORBu, což umožňuje stejné chování ORBů různých výrobců. Důsledkem je potom možnost psát objektové komponenty v heterogením prostředí, tzn. objekty umístěné na různých počítačích v síti s různými operačními systémy a implementované v nejrozmanitějších programovacích jazycích. Popis specifikace CORBA je rovnež popsán v [5].
Pro výše popsané vlastnosti je vhodné použít prostředí CORBA pro implementaci systému, který bude sloužit k uchování a vizualizaci prostorových dat na WWW. Tento systém byl nazván Ddg. Při použití technologie CORBA bude rovněž možné zařazovat do systému komponenty, které vhodně rozšiřují jeho chování. V případě tohoto systému se jedná o měřící a řídící komponenty.
Architekturu systému ukazuje obrázek 1. Nejprve budou zjednodušeně popsány funkce všech komponent v systému. O dynamiku v systému se starají sondy (Probe), jejichž funkcí je zasílání informací o změně své hodnoty DatabaseAdapteru. Nosnou komponentou architektury je DatabaseAdapter. Funkcí DatabaseAdapteru je vykonání požadavku zaslaného klientem (např. 'chci všechny entity v dané vrstvě', 'změň hodnotu sondy', . . . ) nad databází a vrácení výsledku. Dále jsou v systému zakomponovány akční členy (Action). Akční člen hlídá určitou sondu a pokud její hodnota překročí daný limit, dojde k vykonání určité akce. Pro kontrolu hodnot sond a vybuzení příslušného akčního členu je určena komponenta Checker. Kontrola je prováděna vždy, když dojde ke změně hodnoty sondy.
Velmi triviální, ale zároveň důležitá komponenta v systému, je Center. Komponenta Center slouží pro zaregistrování všech poskytovatelů služeb, aby klienti, po získání reference na komponentu Center, mohli těchto služeb využívat. Získání reference na Center může být realizováno tak, že Center vloží svoji referenci do souboru, ze kterého si ji mohou ostatní komponenty načíst. Jestliže komponenta získá referenci na Center, může pomocí jeho metod získat reference i na další objekty a využívat tak jejich služeb.
Obr. č. 1: Architektura systému
Klient slouží k vizualizaci statických i dynamických prostorových dat v běžném WWW prohlížeči s podporou Javy. Forma klienta jako Java applet ([13]) byla zvolena nejen kvůli uživatelskému rozhraní, ale i kvůli možnosti jeho implementace jako přímého klienta DatabaseAdapteru. A zde se skrývá důvod, proč byl do systému přidán WWW server (popis principu WWW serveru i HTTP protokolu je uveden např. v [14]) se servletem ([12]). Objekty v prostředí CORBA běží nad různými ORBy, které spolu komunikují pomocí protokolu GIOP (General Inter-ORB Protocol) nad protokolem TCP. V Internetu ovšem často dochází, z důvodu bezpečnosti, k filtrování paketů na hranicích privátních sítí. U protokolu TCP se jedná o filtrování segmentů s porty, které neposkytují obecně potřebné služby (např. port 80 je využíván HTTP). Komunikace klienta s DatabaseAdapterem by v takovém případě nebyla možná. Z tohoto důvodu byl do architektury vložen servlet, což je Java kód umístěný ve WWW serveru, který je schopen přijímat HTTP požadavky od WWW klientů a zpět posílat HTTP odpovědi. Jako WWW server byl použit Apache ([1]) s modulem JServ ([2]), který umožňuje tomuto WWW serveru spouštět servlety.
Servlet v tomto systému je tedy jakýsi proxy objekt, kterému dochází HTTP požadavky od klienta po nefiltrovaném protokolu TCP (nejčastěji s portem 80), on je dále posílá na DatabaseAdapter a jeho výstup pak předává zpět vizualizačnímu klientovi. Na začlenění servletu do architektury je také výhodná možnost rozmanitých variací klientů, např. data by mohla být generována do HTML.
Jak již bylo řečeno, tak po té, co uživatel vybere množinu sond, bude klient v pravidelných intervalech požadovat hodnoty těchto sond a bude je zobrazovat. Klient tedy bude žádat hodnoty, i když se nezměnily. Tuto neefektivnost řeší objekt Listener běžící v rámci klienta. Komponenta Checker bude informovat Listenera, že hodnota dané sondy s množiny, které on naslouchá, se změnila a Listener poté informuje klienta. Klient bude vyžadovat nové hodnoty množiny sond pouze tehdy, pokud opravdu došlo k jejich změně.
Využití komponenty Listener je možné pouze tehdy, pokud mezi počítačem, na kterém je spuštěn vizualizační klient a počítačem, na kterém je spuštěna komponenta Checker, nebude docházet k výše popsané filtraci paketů a pokud prohlížeč, ve kterém bude klient spoušten, bude schopen vytvořit CORBA server Listener.
Pro uložení dat (prostorových i neprostorových) byl zvolen Oracle8i s modulem Spatial ([8],[9]). Spatial je modul pro práci s prostorovými daty. Tento modul je rovněž popsán v [6]. Systém je ovšem navržen tak, aby byl nezávislý na použité databázi.
DatabaseAdapter přijímá požadavky v dále specifikovaném dotazovacím jazyce (kapitola 4.3) a vrací prostorová i neprostorová data ve formátu XML (specifikace uvedena v [16]). XML (eXtensible Markup Language) je metaznačkovací jazyk umožňující vlastní definici elementů, které dělí dokument do různých částí. Jazyk XML je rovněž popsán v [14]. Důvodem výběru XML bylo, kromě snadné dostupnosti XML parserů (např. [3]), i potřeba použít standard pro výměnu obecných dat, jakým XML bezesporu je. Pro potřeby tohoto systému byla navržena vlastní XML aplikace DdgXML (kapitola 4.2).
Všechny komponenty byly napsány v jazyce Java ([13]), ale jak již bylo řečeno, s ohledem na použití prostředí CORBA, není důvod, proč by jednotlivé objekty nemohly být napsány v jiném programovacím jazyce (samozřejme kromě appletu a servletu). Jako implementace specifikace CORBA 2.3 byl zvolen VisiBroker ([4]).
Komponenty v systému je možno rozdělit na dvě skupiny: poskytovatele služeb (tzv. servery nebo CORBA servery) a klienty těchto služeb (tzv. klienty nebo CORBA klienty). Servery jsou na obrázku 1 vykresleny jako obdelníky se zesílenými okraji. Poskytovatel nějaké služby může být zároveň klientem služby jiného objektu. Služby, které poskytuje server ostatním objektům definují tzv. rozhraní (interface). Toto rozhraní popisujeme pomocí Interface Definition Language (IDL), jehož popis naleznete v [7] a [5]. IDL definice jednotlivých komponent systému Ddg naleznete v [6].
V následujících kapitolách budou podrobněji popsány některé komponenty systému. Podrobný a kompletní popis komponent naleznete v [6].
Měřící a řídící komponenty jsou objekty Checker, Action a Probe. Idea celého mechanismu je následující. Sonda (Probe) měří nějaké vlastnosti reálných objektů (např. stav vody řeky). Naměřené hodnoty zasílá na DatabaseAdapter. Ten je přijme a zapíše do databáze. Akční člen (Action) je prvek, který je přiřazen nějaké sondě s hodnotou zvanou limit. Action je navržen tak, aby byl schopen hlídat více sond najednou. Pro každou sondu, které je akční člen přiřazen, je nastaven vlastní limit. Pokud DatabaseAdapter zjistí, že zaslaný požadavek byl příkazem pro změnu hodnoty nějaké sondy (viz kapitola 4.3), pak volá objekt Checker. Tento objekt nyní zjišťuje, zda nová hodnota sondy nepřekročila limit přiřazeného akčního členu. Pokud je tento limit překročen, je volán příslušný akční člen.
Praktický význam je vysvětlen na následujícím příkladě. Nechť v Olomouci je sonda měřící stav vody na řece Moravě. Této sondě je přiřazen akční člen s limitem 4m. Jestliže by hloubka řeky přesáhla tuto hodnotu, dojde k vyvolání příslušné akce (např. budou informovány složky záchranného systému).
Sonda je prostorová entita s geometrií typu bod, jejíž jedna neprostorová vlastnost je v čase proměnná. Sondy vnášejí do systému dynamické hodnoty, které mohou být zobrazeny klientem. Sondy jsou v systému identifikovatelné svým jedinečným číslem. Dále jsou zavedeny tzv. množiny sond, což jsou sondy, které spolu nějak logicky souvisí. Např. množina sond měřících průtoky na řece Moravě. Množina sond je v systému opět identifikovatelná svým jedinečným číslem. Jedinečná čísla sondy i množiny slouží také jako primární klíče tabulek, do kterých se sondy resp. množiny sond zapisují do databáze (viz kapitola 4.1).
Sonda je navržena jako klient DatabaseAdapteru, který zasílá příkaz pro změnu hodnoty sondy (viz kapitola 4.3). Důvodem návrhu sondy jako klienta bylo, aby zdroj statických i dynamických dat byl soustředěn do jednoho bodu tak, aby klient mohl požadovat tyto data od jednoho objektu.
Komponenta DatabaseAdapter je základní komponentou celého systému. Funkcí tohoto objektu je přijímat požadavky a zpět vracet prostorová i neprostorová data. Aby komponenta mohla korektně pracovat, musí získat referenci na Center a zaregistrovat se u něj, aby klienti DatabaseAdapteru mohli využívat jeho služeb.
Základním problémem při návrhu této komponenty bylo zvolení formy vstupních požadavků a výstupních dat. Pro formu vstupních požadavků byla zvolena pevně daná podmnožina dotazovacího jazyka SQL, která bude popsána v kapitole 4.3. Jazyk byl navržen tak, aby byl nezávislý na použité databázi. Výstupem DatabaseAdapteru bylo zvoleno XML ([16], [14]) jako standardní formát pro výměnu dat. Byla sestavena XML aplikace DdgXML, která poskytuje elementy pro přenos prostorových i neprostorových dat potřebných v systému. Tato XML aplikace bude představena v kapitole 4.2. Kompletní popis pak naleznete v [6]. Jestliže vstupem pro DatabaseAdapter je na databázi nezávislý dotazovací jazyk a výstupem dokument DdgXML, je zaručeno stejné chování DatabaseAdapteru, ať již je implementován pro jakoukoli databázi. V práci byl DatabaseAdapter implementován pro Oracle8i Spatial (viz kapitola 4.4).
Analýza databázového schématu
Veškerá data v systému budou uložena v databázi, ke které bude přímo přistupovat pouze DatabaseAdapter. V databázi budou evidovány seznam vrstev, množiny sond, sondy a vrstvy.
Seznam vrstev je určen k registraci jednotlivých vrstev. V tomto seznamu budou evidovány jedinečné číslo vrstvy, jméno vrstvy a popis vrstvy. V systému bude možno vytvářet hierarchie vrstev, tzn. vrstva může mít nadvrstvu. Např. vrstva politických hranic je nadvrstvou vrstvy hranice krajů. Vzhledem k velkému množství možných vrstev, které budou uloženy samostatně a které v analýze není vůbec možno postihnout, by bylo vhodné evidovat v seznamu vrstev i název tabulky, ve které jsou uloženy jednotlivé entity dané vrstvy.
V databázi budou evidovány vrstvy obsahující entity se stejnými neprostorovými vlastnostmi. U každé vrstvy bude evidováno jedinečné číslo entity vrstvy, jméno entity a geometrie entity. Geometrie je tvar entity popsaný v nějakém souřadném systému. Další evidované vlastnosti závisí na konfiguraci konkrétní vrstvy.
Dále bude evidován seznam množin sond. Množina sond je skupina sond, které spolu logicky souvisí, např. množina sond měřících stav vody na řece, množina sond snímajících hodnoty znečištění ovzduší atd. U každé množiny sond bude evidováno jedinečné číslo množiny sond, jméno množiny a popis množiny. Pro každou množinu bude evidováno, ke které vrstvě tato množina sond přísluší.
V databázi budou evidovány jednotlivé sondy. U sond bude uchováváno jedinečné číslo sondy, jméno, popis, pozice sondy, aktuální hodnota a datum posledního zápisu hodnoty. Pro každou sondu bude evidována množina sond a entita, ke které sonda náleží.
Návrh databázového schématu
Lineární zápis entitních typů definovaný dle předchozí analýzy je následující:
LAYER(ID_LAYER, NAME, DESCRIPTION, TABLE_NAME, OVERLAYER)
COMMUNITY(ID_ENTITY, NAME, POPULATION, ID_LAYER)
PROBES_SET(ID_PROBES_SET, NAME, DESCRIPTION, ID_LAYER)
PROBE(ID_PROBE, NAME, DESCRIPTION, X, Y, VALUE, DATER,
ID_PROBES_SET, ID_ENTITY)
Entitní typ COMMUNITY jako ukázka tabulky vrstvy. Pro každou vrstvu je vytvořena zvláštní tabulka, která obsahuje prostorové i neprostorové vlastnosti entit vrstvy. Atributy ID_ENTITY, NAME a ID_LAYER jsou povinné. Další atributy jsou uživatelsky konfigurovatelné. Pro každou takto vytvořenou tabulku je nutné vytvořit nový záznam v tabulce LAYER a jako hodnotu atributu TABLE_NAME vložit jméno vytvořené tabulky. Např. v tabulce COMMUNITY jsou uloženy obce. Hodnota LAYER.TABLE_NAME musí být 'COMMUNITY'. Tabulka COMMUNITY neobsahuje atribut GEOMETRY, ve kterém je uložena geometrie entity, protože typ, popřípadě další tabulky nutné pro uložení geometrie, jsou závislé na konkrétní databázi popř. modulu pro práci s prostorovými daty této databáze.
V této kapitole bude představena XML ([16], [14]) aplikace DdgXML. DdgXML dokument je určen k přenosu dat od DatabaseAdapteru ke klientovi. V dokumentu DdgXML existují elementy pro přenos prostorových i neprostorových dat. A v tomto se skrývá důvod, proč nebyla využita nějaká existující XML aplikace. Některé existující XML aplikace pro popis vektorové grafiky (např. SVG [17]) dávají sice k dispozici velkou množinu elementů pro různé grafické prvky, ale grafika nejsou jediná data, která je nutno v tomto systému přenášet. V takovýchto XML aplikacích nejsou k dispozici elementy pro přenos obecných dat, a proto byla navržena XML aplikace splňující potřeby tohoto systému.
DatabaseAdapter generuje a vrací klientovi DdgXML dokument na základě jeho požadavku v dotazovacím jazyce, který je popsán v kapitole 4.3. V této kapitole je rovněž uveden příklad DdgXML dokumentu vygenerovaného pro konkrétní příkaz v dotazovacím jazyce.
Tato kapitola obsahuje popis dotazovacího jazyka, jehož příkazy přijímá DatabaseAdapter. Tento jazyk je pevně zvolenou podmnožinou SQL. Důvod, proč byla zvolena tato varianta, byl ten, že bylo nutné, aby příkazy, které přijímá DatabaseAdapter byly nezávislé na použité databázi. SQL je sice nezávislé na databázi, ale jen pokud se používají standardní datové typy.
Některé databáze ovšem disponují různými moduly pro práci s prostorovými daty. Pokud bychom chtěli provést SQL dotaz na databázi, která prostorová data přímo podporuje, určitě by vypadal jinak, než dotaz na klasickou relační databázi obsahující prostorová data. Jestliže vstupem pro DatabaseAdapter bude na databázi nezávislý dotazovací jazyk, je zaručeno stejné chování tohoto objektu ke klientům, ať již bude DatabaseAdapter napsán pro jakoukoli databázi. Výhodou použití takovéhoto dotazovacího jazyka je i jeho snadná rozšířitelnost, např. o prostorové dotazy.
Seznam příkazů dotazovacího jazyka je následující:
Příkaz pro získání seznamu vrstev: SELECT * FROM LAYER
Výsledkem tohoto příkazu je seznam všech vrstev dostupných v databázi, tzn. všech záznamů z tabulky LAYER.
Příkaz pro získání všech entit vrstvy: SELECT * FROM <layer table>
Výsledkem tohoto příkazu jsou všechny entity z vrstvy uložené v tabulce <layer table>. Výsledkem jsou prostorové i neprostorové vlastnosti entit. Tabulka <layer table> musí být obsažena v nějakém záznamu ve sloupci TABLE_NAME tabulky LAYER, tzn. vrstva musí být zaregistrována v tabulce LAYER. Implementace tohoto příkazu bude velmi odlišná pro různé databáze. Pro relační databázi, disponující standardními datovými typy (VARCHAR, NUMBER, atd.), bude pro vykonání tohoto příkazu v implementaci DatabaseAdapteru nutné použít několika SQL příkazů.
Příkaz pro získání seznamu množin sond: SELECT * FROM PROBES_SET
Výsledkem tohoto příkazu je seznam všech množin sond dostupných v databázi, tzn. všech záznamů z tabulky PROBES_SET.
Příkaz pro získání hodnot množiny sond:
SELECT * FROM PROBE WHERE ID_PROBES_SET=<id probes set>
Výsledkem tohoto příkazu jsou informace o sondách, které náleží k množině sond s jedinečným číslem <id probes set>, tzn. všechny záznamy z tabulky PROBE, u kterých se ID_PROBES_SET=<id probes set>.
Příkaz pro aktualizaci hodnoty sondy:
UPDATE PROBE SET VALUE=<value> WHERE ID_PROBE=<id>
DatabaseAdapter po obdržení tohoto příkazu změní hodnotu sondy s jedinečným číslem <id> na hodnotu <value>, tzn. změní hodnotu atributu VALUE na
Příklad:
Následující dokument může být vygenerován pro příkaz SELECT * FROM RIVER.
<?xml version="1.0" encoding="UTF-8"?>
<ddg>
<layers>
<layer height="1.015316009521399" width="5.6725521087647"
x="12.0902938842773" y="50.0425186157227">
<entities>
<entity>
<attributes>
<attribute name="ID_ENTITY">0</attribute>
<attribute name="NAME">RIVER0</attribute>
<attribute name="ID_LAYER">5</attribute>
</attributes>
<geometry>
<shape points="15.1713,50.9968 15.1308,51.0138
15.2713,49.8931"/>
</geometry>
</entity>
...
<entity>
<attributes>
<attribute name="ID_ENTITY">3327</attribute>
<attribute name="NAME">RIVER3327</attribute>
<attribute name="ID_LAYER">5</attribute>
</attributes>
<geometry>
<shape points="12.3956,50.0441 12.4367,50.0573"/>
</geometry>
</entity>
</entities>
</layer>
</layers>
<result code="0">OK</result>
</ddg>
Jelikož se v navrhovaném distribuovaném systému pracuje především s daty prostorovými, jevilo se vhodné nepoužít pro jejich uskladnění klasickou relační databázi, ale nějakou databázi určenou přímo pro práci s prostorovými daty. Pro svou dostupnost byl zvolen modul pro práci s prostorovými daty Spatial databáze Oracle8i ([8],[9]). DatabaseAdapter implemenovaný v tomto systému je tedy určen pro tento modul. Modul Spatial je rovněž popsán v [6].
Modul Spatial poskytuje relační a objektově-relační model. V objektově-relačním modelu je jedna vrstva uložena v jedné tabulce. Neprostorové vlastnosti entity jsou uloženy v atributech se standardními datovými typy. Geometrie entity je uložena ve sloupci typu SDO_GEOMETRY, který je definován takto:
CREATE TYPE sdo_geometry AS OBJECT (
SDO_GTYPE NUMBER,
SDO_SRID NUMBER,
SDO_POINT SDO_POINT_TYPE,
SDO_ELEM_INFO MDSYS.SDO_ELEM_INFO_ARRAY,
SDO_ORDINATES MDSYS.SDO_ORDINATE_ARRAY);
Pokud jsou uložená data bodová, pak jsou uložena v SDO_POINT. Pokud ne, jsou uložena v SDO_ORDINATES. Ostatní prvky typu slouží pro uložení dalších informací např. o typu geometrického prvku uloženého v SDO_ORDINATES (tzn. např. jestli se jedná o řetězec čar nebo mnohoúhelník, atd.). Typ SDO_GEOMETRY je poměrně komplikovaný, podrobnější popis typu a práce s ním naleznete v [6].
Pro komunikaci s databází bylo použito JDBC ([11]). V [6] je rovněž popsáno jakým způsobem lze pomocí JDBC získávat data z objektově-relačního modelu databáze Oracle resp. modulu Spatial.
Tabulka COMMUNITY (viz kapitola 4.1) představující ukázku tabulky vrstvy (v tomto případě vrstvy obcí), má ve Spatialu strukturu uvedenou v tabulce 1.
| Atribut | Datový typ |
| ID_ENTITY | NUMBER |
| NAME | VARCHAR2(30) |
| POPULATION | NUMBER |
| GEOMETRY | MDSYS.SDO_GEOMETRY |
| ID_LAYER | NUMBER |
Tabulka č.1: Tabulka COMMUNITY pro Oracle8i Spatial
Klient je aplikace, pomocí níž uživatel komunikuje se systémem, např. zadává vrstvy, které chce, aby byly zobrazeny. Vize je následující. Uživatel spustí na kterémkoli počítači na světě připojeném do Internetu WWW prohlížeč a zadá příslušnou adresu. Po spuštění appletu si může nechat zobrazovat libovolná prostorová data dostupná v systému.
Důvod, proč je klient implementován jako applet ([13]), byl nejen v možnosti vytvoření sofistikovanějšího uživatelského rozhraní, ale i kvůli možnosti napsat takového klienta jako přímého klienta DatabaseAdapteru a ukázat tak i jinou možnost komunikace než pouze pomocí protokolu HTTP ([14]). Implementovaný applet byl nazván DdgApplet. V appletu je možno zároveň ukázat i výhodu komunikace v prostředí CORBA oproti klasickému HTTP řešení a tou je obousměrná komunikace. Takto navržený klient tedy nemusí pouze požadovat nějaké služby, ale v něm vytvořený CORBA server může služby poskytovat a informovat o nich samotného klienta. Takovýmto CORBA serverem je Listener. Tento objekt, bežící přímo v appletu, je zaregistrovaný u Center a jeho služeb tak mohou využívat různí klienti.
Jestliže bude chtít uživatel získávat nové hodnoty množiny sond, pak applet zasílá na DatabaseAdapter (v pravidelných intervalech, např. po pěti sekundách) příkaz pro získání hodnot množiny sond (viz kapitola 4.3). Tento příkaz je zasílán buď přímo nebo nepřímo (přes servlet) na DatabaseAdapter. Výsledkem příkazu je XML dokument, který je klientem parsován a príslušné sondy jsou zobrazeny. Pokud se ovšem hodnoty těchto sond nemění, pak dochází k neefektivnímu a nepotřebnému zatěžování nejen sítě, ale i DatabaseAdapteru pro získávání stále stejného XML dokumentu.
Tuto neefektivitu řeší právě Listener. Jestliže uživatel nastaví nějakou množinu sond, pro kterou chce zobrazovat aktuální hodnoty, je jedinečné číslo této množiny sond nastaveno i v objektu Listener. Dá se tedy řící, že Listener naslouchá nějaké množině sond. Jestliže dojde ke změně hodnoty sondy, pak objekt Checker (viz kapitola 3) zjišťuje, jestli nějaký Listener nenaslouchá této sondě. Jestliže ano, zavolá jeho příslušnou metodu. Listener poté informuje klienta, že došlo ke změně hodnoty nějaké sondy z množiny sond, která má být zobrazována. Klient si pak vyžaduje hodnoty množiny sond pouze tehdy, pokud došlo k jejich změně a nedochází tak ke zbytečné komunikaci.
Prostřednictvím uživatelského rozhraní klienta si může uživatel vybírat, zda chce zobrazit seznam vrstev nebo množin sond, popř. kterou vrstvu nebo množinu sond z těchto seznamů chce zobrazit. Po výběru, applet vygeneruje příslušný příkaz a zašle jej DatabaseAdapteru, buď přímo nebo v těle HTTP požadavku metody POST ([14]) přes servlet. Vrácený XML dokument je zpracováván dle obsahu. Např. pokud obsahuje entity nějaké vrstvy, pak jsou tyto entity zobrazeny. Atributy a geometrie těchto entit se zapisují do struktur tak, aby v paměti zabíraly co nejméně místa. Pokud se budou data ukládat do paměti, pak je klient nemusí pro další práci s nimi (např. při změně měřítka) znovu požadovat od DatabaseAdapteru. To je nutné zejména kvůli možnému objemu prostorových dat (až jednotky MB) a tím danou delší dobou získávání dat z databáze, vytváření XML dokumentu a přenosu dat po síti.
Předchozí kapitoly popisovaly navržený a implementovaný distribuovaný systém v prostředí CORBA schopný uchovávat a vizualizovat data na WWW.
Obr. č. 2: Klient systému se zobrazenými okresy a vodními toky České republiky
Systém se podařilo navrhnout tak, že jeho implementace reálně funguje. Data jsou přístupná pomocí služby komponenty DatabaseAdapter, jejímž vstupem je příkaz nezávislý na použité databázi a výstupem XML dokument. Tyto rysy umožňují budoucí snadné rozšíření, např. o prostorové dotazy. DatabaseAdapter byl implementován pro modul pro práci s prostorovými daty Spatial databáze Oracle8i, a byla tak vyzkoušena použitelnost tohoto modulu pro reálné aplikace. V rámci práce byla vytvořena jednoduchá aplikace OracleManager využívající Oracle Spatial Java Class Library ([10]), která umožňuje konverzi souborů ESRI shapefile (které se v GIS reálně používají) do Oracle Spatial.
Klient systému byl implementován jako applet a to nejen kvůli možnosti vytvoření sofistikovanejšího uživatelského rozhraní, ale i kvůli možnosti využití technologie CORBA v takovém klientovi. Klient tedy nemusí komunikovat s ostatními komponentami zprostředkovaně pomocí protokolu HTTP přes servlet, ale může s nimi komunikovat přímo. Nelze zapřít, že ne všechny WWW prohlížeče jsou schopny spouštět applety, které se chovají jako CORBA klienti a nebo vytvářet CORBA servery. Vzhledem k relativnímu mládí této distribuované technologie a již k dnes hmatatelným výsledkům, se dají očekávat takové implementace technologie CORBA a WWW prohlížečů, které budou schopny reálného použití.
Koncipovat klienta pouze jako CORBA klienta je spíše intranetovou záležitostí, vzhledem k již popsané možné filtraci paketů na hranicích jednotlivých privátních sítí. Vzhledem k této skutečnosti a k ne příliš dokonalé funkčnosti distribuované technologie CORBA v současných prohlížečích se ukázalo jako velmi vhodné vložit do architektury WWW server se servletem. Přenos dat od DatabaseAdapteru přes servlet ke klientovi pomocí protokolu HTTP je pomalejší než v případě přímé komunikace mezi klientem a DatabaseAdapterem a zároveň nejsou dostupné služby objektu Listener. Ale za to na oplátku získáváme funkčnost klienta umístěného kdekoli v Internetu a spuštěného v libovolném prohlížeči s podporou Javy.
Obr. č. 3: Klient systému se zobrazenými okresy ČR a třemi sondami na řece Moravě
Na obrázcích 2 a 3 vidíme ukázky klientů tohoto distribuovaného systému. Na obrázku 3 vidíme klienta, který zobrazil vrstvu okresů a aktuálně zobrazuje hodnoty tří sond měření stavu vody na řece Moravě. Implementace klienta jako appletu přináší jednu nespornou výhodu a tou je nezávislost na platformě. Klienta lze spouštět na libovolné platformě, kde je k dispozici WWW prohlížeč s podporou Javy. Funkčnost klienta byla otestována na platformách Windows (obrázek 3) a Linux (obrázek 2).
Tento článek prezentoval diplomovou práci jejímž účelem bylo vytvořit distribuovaný systém, který by byl schopen uchovávat prostorová data, vizualizovat je na WWW a zároveň rozšířit systém o měřící komponenty pro sběr dynamických hodnot atributů prvků a komponenty, které kontrolují tyto hodnoty. V rámci práce byla navržena vhodná a rozšiřitelná architektura takovéhoto systému, která byla i prakticky realizována a odzkoušena její implementace.
Recenzoval: Ing. Jan Růžička (VŠB - TU Ostrava)