MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
EJB komponenta pro efektivní ukládání SVG obrázků
DIPLOMOVÁ PRÁCE
Petr Nehyba
Brno, 2012 Prohlášení
Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Vedoucí práce: RNDr. Radek Ošlejšek, Ph.D.
ii Poděkování
Děkuji RNDr. Radkovi Ošlejškovi, Ph.D. za jeho čas a cenné rady, které mi věnoval.
iii Shrnutí
Cílem diplomové práce je popsat možnosti ukládání SVG obrázků. Dále je shrnuto jak vytvořit Enterprise Java Bean komponentu, která umožňuje ukládat a vyhledávat anotované SVG obrázky. V práci je popsán tento grafický formát včetně rozšíření o anotační část vytvořenou pro účely projektu GATE. Dále jsou popsány možnosti ukládání XML dat. Práce poskytuje přehled open source XML databází. Poslední část se věnuje výběru nejvhodnějšího řešení a jeho implementaci.
iv Klíčová slova: SVG, ASVG, G.A.T.E., EJB 3.1, Java EE 6, Nativní XML Databáze (NXD), BaseX, MonetDB, BerkeleyDB, Qizx, Sedna
v Obsah 1 Úvod ...... 1 2 SVG...... 2 2.1 Struktura SVG formátu...... 2 2.2 Anotované SVG obrázky...... 4 2.2.1Ukázka anotovaného SVG...... 4 2.2.2Rozbor ukázkového ASVG...... 6 2.2.2.1 Metadata...... 7 2.2.2.2 Polygony...... 8 3 Ukládání XML do databáze...... 9 3.1 Rozdělení XML dokumentů...... 9 3.1.1Datově orientované XML...... 9 3.1.2Dokumentově orientované XML...... 10 3.1.3Zařazení anotovaného SVG...... 10 3.2 Rozdělení XML databází...... 11 3.2.1XML-enabled databáze...... 12 3.2.2XML nativní databáze...... 12 4 Nativní XML databáze...... 13 4.1 Aplikační programové rozhraní...... 14 4.1.1JDBC...... 14 4.1.2XML:DB API...... 15 4.1.3XQJ...... 16 4.1.4Webová API...... 17 4.1.5Vlastní API...... 17 4.2 Dotazovací jazyky...... 18 4.2.1XPath...... 18 4.2.2XQuery...... 18 4.2.3XUpdate...... 19 4.2.4XQuery Update Facility...... 20 4.3 Seznam nekomerčních NXD...... 20 5 Projekt...... 21 5.1 Funkční požadavky...... 21 5.2 EJB komponenta...... 22 5.2.1Druhy EJB...... 23 5.2.2Implementace ...... 24 5.3 Sestavení XQuery dotazů...... 26 5.3.1Hledání v anotacích...... 27 5.3.2Hledání v polygonech...... 27 5.4 Klientská aplikace...... 28 5.5 Vybrané nativní XML databáze...... 28 5.5.1BaseX ...... 29 5.5.1.1 Příklad použití vlastního API...... 30 5.5.2Berkeley DB XML ...... 30
vi 5.5.2.1 Příklad použití...... 31 5.5.3MonetDB/XQuery ...... 31 5.5.3.1 Příklad použití JDBC...... 32 5.5.4Qizx ...... 32 5.5.4.1 Příklad použití...... 32 5.5.5Sedna...... 33 5.5.5.1 Příklad použití XQJ...... 33 5.5.5.2 Příklad použití XML:DB API...... 34 5.5.6Hodnocení vybraných NXD...... 35 5.6 Test výsledné aplikace...... 35 5.7 Nastavení a možná rozšíření aplikace...... 37 6 Závěr...... 38
vii 1 Úvod
Informační technologie jsou jedním z nejrychleji se rozvíjejících odvětví techniky. Lidstvo generuje stále více a více dat, nejen proto je potřeba vytvářet nástroje na uchovávání těchto informací. Každé odvětví lidské činnosti má své specifické potřeby, proto jde dopředu i vývoj různých databázových řešení. Ty tam jsou doby, kdy veškerým potřebám organizace postačovala relační databáze s několika tabulkami. Kvůli transformacím a agregaci dat je často vhodnější použít buďto nástavby nad klasickými databázemi a nebo přístupy zcela odlišné. Tato práce má za cíl prostudovat a popsat efektivní ukládání XML dat do databáze. Jedná se zejména o strukturovaný způsob (po XML elementech). SVG je deskriptivní značkovací jazyk rozšiřující standart XML. Díky své flexibilitě je tento grafický formát v poslední době často používán k zpřístupnění objektově orientované vektorové grafiky. Flexibilita formátu umožňuje použít SVG i pro rastrovou grafiku, zejména fotografie. Pro účely projektu GATE (Graphics Accessible to Everyone) [1] vytvořím serverovou komponentu, která umožní ukládat a vyhledávat obrázky podle jejich anotace. Úvodní část práce je stručným popisem formátu SVG. Navazuje popis rozšíření o anotaci v rámci projektu GATE, což umožňuje informovat uživatele o grafickém obsahu nevizuální formou. Pro názornost uvádím rozbor vzorového ASVG obrázku, který později poslouží ke stanovení požadavků na databázové řešení. Třetí kapitola popisuje možnosti ukládání XML dat do databáze a jednotlivé varianty těchto řešení. Další kapitola se zabývá nativními XML databázemi, jejich hlavní charakteristikou, podporovanými jazyky pro práci s XML a standardním aplikačním rozhraním. Důraz je kladen na open source technologie. Následuje projektová část, kde jsou nejprve popsány možnosti EJB technologií a vytvoření serverové EJB komponenty, dále navazuje návrh řešení pro ukládání anotovaných SVG obrázků. Popsáno je několik XML nativních databází a jejich nasazení. Poslední část kapitoly demonstruje vytvořenou testovací aplikaci, která zpřístupňuje funkcionalitu serverové komponenty. Závěr se věnuje hodnocení dosažených výsledků. Navrhnuta jsou možná rozšíření a upřesnění o další funkcionality.
1 2 SVG
SVG (Scalable Vector Graphics) je v obecném smyslu jazyk, formát, platforma. Slouží pro popis dvoudimenzionální grafiky založeném na XML. Umožňuje popsat vektorovou grafiku a to jak statickou, tak dynamickou. Jedná se o otevřený standart vyvíjený organizací W3C [2]. Platforma SVG vyplňuje mezeru mezi grafickými formáty používanými na internetu. Podporuje tři typy grafických objektů: vektorovou grafiku, rastrové obrázky a klasický text. Tyto objekty mohou být vloženy dohromady v jednom SVG obrázku a podle dostupných funkcí upraveny. Díky podpoře XML jmenných prostorů je obsah lehce přístupný a prohledatelný např. moderními dotazovacími jazyky [3]. V době psaní této práce je aktuální verze 1.1, poslední úprava je z 16. srpna 2011. Kromě této standardní verze existují i dvě varianty pro mobilní zařízení [4]. SVG Tiny (SVGT) je určeno pro mobilní telefony, SVG Basic (SVGB) je vhodné pro PDA. Tyto verze jsou ochuzeny o některé funkce, mají nižší počet atributů a hodnoty jsou omezeny. Standart se v tomto snaží vyjít vstříc nižšímu výpočetnímu výkonu a propustnosti malých zařízení.
2.1 Struktura SVG formátu Formát SVG je založen na XML. V textové formě je popsaná struktura a lze s ní nakládat stejně jako s XML soubory. SVG definuje tři základní typy grafických objektů: • vektorové tvary (např. obdélník, kružnice, elipsa, úsečka, polygon a křivka) • rastrové obrázky • textové objekty
Vykreslením všech elementů (objektů) vznikne konečný obrázek. U vektorových tvarů je možné nastavit mnoho způsobů vykreslení (okraje, výplně, průhlednost atd.) a v čase lze tyto atributy měnit. Tím je umožněno vytvořit animace podobně jako u formátu Flash. Ze zdrojového kódu níže se ať už editorem, prohlížečem nebo zásuvným modulem vygeneruje statický 2D obrázek (Obr. 1) .
2
Obr. 1: ukázka SVG
Jak je z uvedeného zdrojového kódu vidět (Ukázka 1), každý element XML dokumentu reprezentuje právě jeden grafický prvek. To umožňuje ovlivňovat výslednou podobu kresby úpravou jednotlivých uzlů např. editací objektového modelu dokumentu (Document Object Model) [5]. V dnešní době
3 existuje spousta editorů pro tento formát, tato ukázka byla vytvořena v online nástroji [6].
2.2 Anotované SVG obrázky V rámci projektu GATE (Graphics Allowed To Everyone) byl vytvořen takzvaný ASVG formát [1]. Do části metadat SVG obrázku (s vloženou fotografií) byla přidána anotační část, která popisuje obsah obrázku. Vektorové tvary vložené na konec souboru umožňují vyznačit jednotlivé objekty a pomocí metadat lze tyto anotace propojit s ontologiemi.
2.2.1 Ukázka anotovaného SVG Následující obrázek ukazuje jednotlivé polygony ohraničující vyznačené objekty. Ve výsledném obrázku jsou pochopitelně skryty. Editor pro anotaci obrázků vytvořil Bc. Jaromír Nyklíček v rámci své bakalářské práce: Anotátor SVG obrázků [7].
Obr. 2: anotovaný obrázek SVG
4 Velice zkrácená ukázka kódu z předchozího obrázku (Obr. 2) vypadá následovně. Další obrázek (Obr. 3) znázorňuje strukturu metadat:
Ukázka 2: kód anotace v části metadat
5 Obr. 3: ukázka struktury metadat v programu BaseXStudio
2.2.2 Rozbor ukázkového ASVG Formát SVG je vystavěný nad XML standardem. Už z principu má nepravidelnou strukturu a obsah obrázku typu ASVG je smíšený. Vzhledem k tomu, že v dalších kapitolách se věnuji již konkrétním oblastem ukládání dat a volbou vhodných nástrojů, je dobré si ujasnit, jak takový typický obrázek ASVG vypadá. To později poslouží ke stanovení požadavků a omezení na použitý software. Velikost obrázku je z principu neomezená, záleží čistě na požadované kvalitě. Stejně tak hloubka popisu může být velice rozmanitá. Mnou vybraný anotovaný vzorový obrázek (viz. obr 2) má velikost 2331 kB při rozlišení 1024 x 768 pixelů. Soubor obsahuje 130 řádků a je v něm vložena fotografie formátu PNG. Fotografie je uložena v elementu
6 definicí SVG a XML šest jmenných prostorů. Na fotografii jsou identifikovány čtyři základní objekty (landscape, sky, praded, transmitter). Ty se dále dělí na další a další. Celkově je to čtrnáct grafických objektů typu gate, které mají další vlastnosti jako např. barvu a umístění. Následuje popis části metadat, aby bylo jasné, která data budeme z obrázku načítat. Druhá podkapitola ilustruje vyznačení objektů ve fotografii převážně pomocí polygonů.
2.2.2.1 Metadata Komponenta bude moci vyhledávat na základě obsahu prvku v sekci metadat. Zde je hierarchicky uvedeno z jakých částí a podčástí se obrázek skládá. Hlavní část:
Vyhledávání SVG obrázků na základě subjektů uvedených v anotační části bude tedy realizováno procházením této hierarchické struktury. Využít k tomuto účelu lze tedy buďto atribut přímo grafického objektu (rdf:ID="sky") nebo atributy jeho potomků označujících složení (rdf:resource="#tree1").
7 2.2.2.2 Polygony Druhá funkce komponenty je možnost vyhledávat obrázky, které obsahují podobjekt s určitým ID. Tyto podobjekty jsou ve výsledném obrázku skryty, u obrázku (Obr. 2) je ponechána viditelnost křivek kvůli ilustraci. Ke konci souboru je uvedena tato struktura převážně polygonů popisujících jednotlivé podobrazce, ty mohou být rovněž zanořené a seskupené do grup:
Vyhledávání obrázků na základě ID bude tedy procházením této stromové struktury. Jednotlivé atributy ID jsou pro přehlednost v předchozí ukázce zvýrazněny tučně.
8 3 Ukládání XML do databáze
Formát XML se stal univerzálním formátem pro výměnu dat. Používá se pro komunikaci prostřednictvím internetu ve velmi různorodých oblastech: od obchodních partnerů vyměňujících si dokumenty v docx formátu (Office Open XML) až po intenzivní síťovou komunikaci přes Web service. Všechna tato data je potřeba efektivním způsobem ukládat Důležité není jen skladovat a uchovávat informace, ale je potřeba mít možnost je třídit a prohledávat podle kritérií [8]. Tato kapitola se proto nejprve snaží čtenáři vysvětlit, jak můžeme rozdělit XML dokumenty podle jejich použití a obsahu. Druhá část se věnuje rozdělení dostupných databázových řešení, která jsou určená pro zpracování XML dokumentů.
3.1 Rozdělení XML dokumentů Podle obsahu a použití můžeme rozlišit dva typy XML dokumentů. Obě skupiny mají trochu jiné charakteristiky a toto rozdělení může později posloužit jako základ pro volbu typu XML databáze.
3.1.1 Datově orientované XML Datově orientované XML dokumenty mají pravidelnou předdefinovanou strukturu. Jsou určeny primárně pro transport dat a slouží pro strojové zpracování. Většinou u nich nezáleží na pořadí elementů a vyjímečně obsahují složené elementy. Nejběžnějším, často uváděným, příkladem je zjednodušená forma faktury:
9 3.1.2 Dokumentově orientované XML Dokumentově orientované XML dokumenty nemají pravidelnou ani předem definovanou strukturu. Primárně jsou určeny a vytvářeny lidmi. Zpravidla obsahují smíšený obsah, který je utvořen složením textu a zanořených elementů. Pořadí všech elementů je zásadní, takže nemůže být nic přehozeno nebo načteno v jiném než originálním uspořádání. Jako ilustraci uvádím ukázku z dokumentu zpracovaného značkovacím jazykem DocBook [9].
3.1.3 Zařazení anotovaného SVG Kam ale zařadit anotovaný SVG obrázek? Jeho struktura má jen částečně danou hierarchii, která je tvořena např. editorem. Ale i tak lze psát kód ručně a obsah může být smíšený. Nelze ho proto zařadit ani do jedné kategorie a proto anotované SVG můžeme označit jako tzv. hybridní XML dokument.
10 3.2 Rozdělení XML databází Nejprve si ujasníme, co vlastně heslo „XML databáze“ znamená. Tímto tématem se zabývá organizace iniciativa XML:DB [10], která si dala za cíl formulovat a specifikovat technologie pro zacházení s daty v XML databázích. Komunita okolo XML:DB initiave uvedla tři různé definice typů XML databází: 1. Nativní XML databáze (NXD) a) Definuje (logický) model pro XML dokumenty, podle kterého je ukládá a načítá. Model musí při nejmenším obsahovat elementy, atributy, PCDATA [11] a informace o pořadí. Příkladem těchto modelů jsou XPath datový model, XML Infoset [12] a modely vycházející z DOM [5] a událostí v SAX 1.0 [13]. b) Mají XML dokument jako základní (logickou) jednotku úložiště, stejně tak jako relační databáze mají řádek jako svou základní jednotku v tabulce. c) Není zde potřeba mít nějaké určité základní fyzické úložiště modelu. Např. může být vystavěna nad relační, hierarchickou nebo objektově orientovanou databází, nebo použít proprietární formát úložiště jako např. indexované, komprimované soubory. 2. XML-Enabled databáze (XEDB) Databáze, které jsou rozšířené o XML mapovací vrstvu, kterou poskytl buďto přímo prodejce nebo třetí strana. Tato mapovací vrstva řídí ukládání a načítání XML dat. Data, které jsou mapována do databáze, jsou namapována na specifický formát a původní XML meta-data a struktury mohou být ztraceny. Není garantováno, že získaná data z databáze odpovídají původní formě. K tomu může dojít manipulací s daty prostřednictvím technologií XML (např. XPath, XSLT [14], DOM [5], nebo SAX [13]) nebo jiné technologie (např. SQL). Proto základní jednotka uložení je v XEDB implementačně závislá. Řešení od Oracle a Microsoftu stejně tak jako od dalších dodavatelů spadá do této kategorie. 3. Hybridní XML databáze (HXD) Do této kategorie patří databáze, které mohou být považovány jak za nativní, tak za databáze XML-enabled. To závisí na tom, jaké jsou požadavky aplikace. Zástupcem této kategorie je často označovaná databáze Ozone, která bohužel v době psaní této práce není aktivní.
11 3.2.1 XML-enabled databáze Jak z předchozí definice XML:DB iniciativy vyplývá, XML-enabled databáze obsahují rozšíření o mapovací nástroje. Díky tomu lze převádět XML dokumenty do databáze a pak je zpětně získávat zase v XML formátu. Primárně jsou určeny pro datově orientované dokumenty, protože ty mají pevně danou strukturu. Dopředu je známo schéma dokumentu a tím pádem je možné importovat dokument do připravené množiny. Relační databáze ukládají XML dokumenty buďto jako textové řetězce nebo mají vlastní datový typ XML. Příkladem takové databáze může být třeba MySQL [15].
3.2.2 XML nativní databáze Tyto databáze jsou specializované na ukládání XML dokumentů a XML dokument je pro ně základní logická jednotka. Ty se sdružují do kolekcí a manipulovat s nimi lze v rámci celé kolekce i v rámci jednotlivých dokumentů (podčástí). To znamená, že takto uložené dokumenty lze snadno indexovat, prohledávat a v neposlední řadě i upravovat. Jak z definice XML:DB vyplývá, není zde důležité jaké je použité fyzické úložiště (např. relační databáze nebo objektově orientované databáze), ale podstatné je, že tyto databáze zachovávají fyzickou strukturu dokumentu. U většiny nativních XML databází lze ukládat dokumenty bez znalosti jejich schéma, jsou tedy vhodnější pro dokumentově orientované XML dokumenty, které nemají pravidelnou strukturu jak bylo vysvětleno v sekci 3.1.2. Pro účely tohoto projektu jsou tedy vhodnější než XML-enabled databáze, protože SVG obrázek lze považovat za tzv. hybridní typ XML dokumentu, jak bylo stanoveno v kapitole 3.1.3. Důležité je, že nativní XML databáze zachovávají fyzickou strukturu a není potřeba načítat schéma dokumentu. Proto se jim věnuje více do hloubky následující kapitola.
12 4 Nativní XML databáze
Obsahem následující kapitoly je popis charakteristik nativních XML databází (NXD). V předchozí kapitole jsme si ujasnili jak lze kategorizovat XML dokumenty a jaké databáze lze použít. Z toho je odvozeno, že nejvhodnějším typem databáze pro ukládání SVG obrázků je XML nativní. Vyčerpávajícím zdrojem informací o tomto typu databází je bezesporu stránka konzultanta, vývojáře a výzkumníka Ronalda Bourreta [16]. Ten se ve své kariéře již přes deset let věnuje tématu XML produktů. Díky tomu se z něj stal guru v oblasti těchto technologií. Následující fakta jsou čerpána převážně z jeho stránek nejen díky přehlednosti a obsáhlosti jeho práce, ale také proto, že nikde jinde neexistuje v tomto směru obsáhlejší a kvalitnější zhodnocení dané problematiky.
Architekturu XML nativních databází lze rozdělit do dvou kategorií: • Textově orientované NXD ukládají XML data jako text. K tomu používají např. soubor v souborovém systému, BLOB [17] nebo CLOB [18] položku v relační databázi. Díky indexaci může dotazovací stroj skočit do kteréhokoliv místa v libovolném XML dokumentu. To umožňuje rychle načítat části nebo celé dokumenty. Na druhou stranu, pokud nejsou data uložena ve stejném pořadí, jako je XML hierarchie dokumentu, tak může dojít ke značnému zpomalení.
• Modelově orientované NXD neukládají XML data jako text, ale vytvoří si vnitřní objektový model dokumentu. Uložení modelu je u tohoto typu databází různé. Některé používají relační nebo objektové databáze, jiné mají vlastní proprietární způsob pro daný model. Výkon a rychlost pak závisí na použité databázi, nad kterou jsou vybudovány. Proto jsou výkonově srovnatelné s textově orientovanými databázemi, ale s tím rozdílem, že obecně jsou rychlejší při načítání dokumentů do DOM [5]. Textově orientované databáze jsou obecně rychlejší při vracení XML dokumentu jako text. Stejně jako u prvního typu i u těchto databází může docházet ke zpomalení při načítání dat v jiném pořadí, než jak jsou uložena.
13 Dále lze NXD rozdělit podle jejich schopnosti integrace do programu. Některé fungují pouze jako komponenta, která umožňuje přístup k datovému souboru (na lokálním disku), který reprezentuje databázi. U tohoto typu řešení je potřeba, aby byl program a databáze na jednom počítači. Program vlastně spouští tuto databázi v komponentě a řídí její chod. Druhý typ lze označit jako samostatně stojící databáze (stand-alone) nebo přímo jako databázový server. Ty lze provozovat nezávisle na použitém klientovi a díky tomu lze připojit více typů uživatelů skrz distribuované prostředí (zejména na Internetu). Připojení probíhá pomocí IP adresy, portu, uživatelského jména a hesla. Všechny nativní XML databáze podporují indexování, čímž je dosaženo urychlení při dotazování. Základním typem jsou strukturální indexy, které vytváří ukazatele umístění elementů a atributů. Hodnotové indexy zase sumarizují hodnoty atributů a textové uzly. Díky těmto dvěma lze účiněji prohledávat cesty a hodnoty v hierarchii. Třetím typem jsou full-textové indexy, které umožňují vyhledávat dokumenty, které obsahují hledané heslo. Tento typ není běžný u všech NXD. V následujících podkapitolách se zaměříme nejprve na programová rozhraní (API). Druhá část ilustruje použitelné dotazovací jazyky podporované většinou nativních XML databází.
4.1 Aplikační programové rozhraní Všechny nativní XML databáze poskytují alespoň jedno programové rozhraní. Cílem je popsat rozhraní, která jsou stavbou a konstrukcí podobná formátu ODBC (JDBC) [19], který definuje jednotné rozhraní pro přístup k relačním databázím. U všech ukázek, použitých v následujících podkapitolách, je pro jednoduchost vynecháno ošetření chyb a výjimek. Rozsáhlejší ukázky kódů lze nalézt v citovaných odkazech.
4.1.1 JDBC JDBC je primárně určeno pro přístup k relačním databázím, ale lze ho použít i k přístupu k libovolnému formátu dat, uložených ve „sloupcové podobě“. Pro NXD není tedy příliš vhodný, ale i tak ho použít lze. Důkazem toho je MonetDB/XQuery, která tento JDBC ovladač používá. Nejdříve je potřeba nastavit zaváděcí třídu požadovaného JDBC ovladače [19]: Class.forName("com.somevendor.jdbc.Driver");
14 Připojení se naváže pomocí třídy DriverManager a její metody getConnection(): String uri="jdbc:vendor://host:port/database"; Connection con = DriverManager.getConnection(uri,"user","password"); Použití je pak následující: Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery("SELECT * FROM Table"); while ( rs.next() ) { . . .} A když jsme se vším hotoví, je nezbytně nutné vše uzavřít, aby byly uvolněny již nepotřebné zdroje: rs.close(); stmt.close(); conn.close();
4.1.2 XML:DB API Rozhraní XML:DB API je vytvořeno skupinou XML:DB. Je specifikováno poměrně na abstraktní úrovni [20]. Jeho koncepce je velice podobná JDBC. Navíc je členěno do více vrstev. Core Level 0 obsahuje rozhraní pro zdroje (Resource), kolekce (Collection) a služby (Services). Core Level 1 k tomu navíc přidává službu pro Xpath dotazy (XPathQueryService). Nejprve se nastaví požadovaný ovladač: String driver = "org.vendor.product.xmldb.DatabaseImpl"; Class c = Class.forName(driver);
Pak se vytvoří manažer a zaregistruje si díky ovladači instanci databáze: Database database = (Database) c.newInstance(); DatabaseManager.registerDatabase(database);
Následně se zpřístupní kolekce XML dat na udané adrese: String uri = "xmldb:product:///database/collection"; col = DatabaseManager.getCollection(uri);
Vytvoří se dotaz a pomocí služby se nad kolekcí provede: String xpathQuery = ". . ."; XPathQueryService service = (XPathQueryService) col.getService("XPathQueryService", "1.0");
15 Vytvoří se množina výsledků, kterou lze procházet iterátorem: ResourceSet resultSet = service.query(xpathQuery); ResourceIterator results = resultSet.getIterator(); while (results.hasMoreResources()) { Resource res = results.nextResource(); . . . res.getContent(); }
A nakonec je stejně jako u JDBC potřeba uzavřít a uvolnit zdroje: col.close();
Právě množina jednotlivých služeb určuje, co databáze umí. Kromě výše uvedené služby pro XPath dotazy lze použít např. službu pro úpravy a změny (XUpdateQueryService).
4.1.3 XQJ XQuery API pro Javu (XQJ) poskytuje podporu pro vyhodnocování XQuery dotazů nad zdroji XML dat. Je navrženo JCP (Java Community Process) pod označením JSR 225. Konečná verze specifikace je dostupná od 24. června 2009 [21,22, 23]. Nejdříve vytvoříme instanci zdroje dat (např. tímto zápisem): XQDataSourceImpl dataSource = (XQDataSource) Class.forName("com.jsr225.xqj").newInstance();
Ustanovíme připojení: XQConnection conn = dataSource.getConnection("user", "password"); Vytvoříme výraz a s jeho pomocí provedeme dotaz: XQExpression expr = conn.createExpression(); String query = ". . ."; XQResultSequence result = expr.executeQuery(query); while (result.next()) { . . . result.getValue(); . . . }
16 A nakonec vše uzavřeme: result.close(); expr.close(); conn.close();
4.1.4 Webová API Většina nativních XML databází poskytuje přístup přes webové služby [24]. Serverová aplikace bude využívat API pro použitý programovací jazyk, ale v budoucnu lze těchto služeb využít jako další přístupový bod do databáze:
• XML-RPC [25] je technologie volání vzdálené procedury. Komunikace probíhá na bázi typu klient-server použitím XML-RPC protokolu. Spojení je ustanoveno nad protokolem HTTP a data jsou zapouzdřena do XML. • SOAP [26] je technologie navazující na XML-RPC. Taktéž probíhá komunikace pomocí zpráv založených na XML pomocí HTTP. • REST [27] je webová služba a na rozdíl od předchozích dvou je orientována datově, nikoliv procedurálně. Sémantiku operací tvoří pouze CRUD (create, read, update a detele). • WebDAV [28] je soubor metod založených na HTTP, které usnadňují spolupráci při správě a editaci dokumentů na webovém serveru. Umožňuje měnit datové elementy databáze podobně jako soubory v souborovém systému.
4.1.5 Vlastní API I když se většina výrobců snaží plně implementovat nejnovější univerzální rozhraní, někteří poskytují vlastní (proprietální). Výhodou je, že taková rozhraní jsou na míru ušita jednotlivým programovacím jazykům a ze strany výrobce je dodávána úplná dokumentace včetně funkčních ukázek. Formát přístupu k databázím je však stejný jako u XQJ nebo XML:DB API. Nejprve se ustanoví spojení pomocí adresy, portu a přihlašovacích údajů klienta. Následně lze využít připravené funkce pro komunikaci s databází.
17 4.2 Dotazovací jazyky Protože XML formát se již řadu let nepoužívá jen pro přenos dat, ale i jako úložiště, je potřeba tato data efektivně prohledávat a vytvářet nové strukturované údaje. Standardní dotazovací jazyk SQL v případě XML databází nelze použít, protože je navržený výhradně pro relační model dat [29]. Proto byl vyvinut jazyk XPath a další na něj navazující. V této sekci jsou popsány hlavní dotazovací jazyky použité nativními XML databázemi.
4.2.1 XPath Jazyk XPath, který je dílem konsorcia W3C, pracuje s abstraktním modelem XML dokumentu. Byl primárně určen pro navigaci po stromové struktuře dokumentu. Výsledkem dotazu je posloupnost ať už uzlů nebo přímo hodnot (atributů). Výsledné uzly jsou vždy vráceny v pořadí v jakém se vyskytují v kolekci (popř. v dokumentu). Tyto uzly je možné filtrovat pomocí predikátů a lze použít řadu funkcí pro práci s řetězci, regulárními výrazy a agregační funkce (count, sum, min, max a avg). Nechybí ani práce s časem a datem, zastoupeny jsou i základní matematické operace [30].
4.2.2 XQuery Jazyk XQuery byl primárně navržen jako dotazovací jazyk pro data uložená ve formě XML souboru. Ale jeho dnešním hlavním úkolem je získávat data z XML databází. To zahrnuje nejen nativní XML databáze, ale i ostatní, které umožňují ukládání XML dat (např. nástavby nad relačními databáze). Dokonce lze XQuery použít i pro transformace XML dat např. do XHTML. Tímto se stává přímým konkurentem transformačního jazyka XSLT (Extensible Stylesheet Language Transformation) [14]. Dalo by se říct, že XQuery je nástavbou nad XPath. Využívá jeho schopnosti procházet a navigovat po stromové struktuře XML dat. Doplňuje ho tak, aby bylo možné vytvořené dotazy rozšířit podobně jako v SQL (filtrovat, řadit výsledky). Proto byla vytvořena dotazovací konstrukce FLWOR. Jedná se o zkratku z pěti částí: FOR, LET, WHERE, ORDER BY a RETURN [31]: FOR: Používá se pro iteraci nad množinou uzlů (typicky kolekcí dokumentů). LET: Tímto je možné ukládat do proměnných specifické poduzly a dále s nimi pracovat např. v rozhodovacím stromu, nebo při dalších podmínkách.
18 WHERE: Filtruje vybrané uzly pomocí podmínek. ORDER BY: Upravuje uspořádání výsledné sekvence podle určitého kritéria (např. podle abecedy). RETURN: Vrací výstup z celého dotazu. Zde lze upravit formu výstupu a tím data transformovat.
Následující ukázka XQuery dotazu vypíše seznam oblíbených zákazníků z kolekce zákazníků, kteří mají v databázi objednávek více jak 500 záznamů, seřazených podle příjmení: for $customer in collection("CustomersDB")//customer let $order:= collection("OrdersDB")// order[id_cust=$customer/@id] where count($order>500) order by $customer/surname return
Ukázka možného výstupu dotazu:
4.2.3 XUpdate XUpdate je jednoduchý dotazovací jazyk pro úpravu XML dat. Specifikace byla vyvíjena iniciativou XML:DB a jejím cílem je nejen možné úpravy XML dokumentů, ale i úprava XML dat v databázi. Umožňuje úpravu, přidání, přejmenování a smazání elementu, atributu nebo celého uzlu.
19 4.2.4 XQuery Update Facility Jedná se o rozšíření jazyka XQuery, které vytváří dotazy, které mohou být použity k úpravě XQuery 1.0 a XPath 2.0 datového modelu. 17.března byl tento standart dokončen jako W3C Recommendation [32].
4.3 Seznam nekomerčních NXD Následující tabulka je přehledem dostupných open source databází. Licence se u některých různí, některé jsou volné pouze pro nekomerční účely a nejsou tedy open source, ale pro potřeby tohoto projektu je to dostatečné. Sloupec „základní typ“ označuje použitou základní databázi jako model úložiště. Seznam čerpá většinu informací z webových stránek Ronalda Bouretta [16].
Název databáze: Výrobce: Základní typ: 4Suite FourThought oběktově-orientovaný BaseX University of Konstanz proprietární Berkeley DB XML Oracle Berkeley DB (klíč-hodnota) DBDOM Ari Krupnikov relační dbXML dbXML Group proprietární eXist Wolfgang Meier proprietární eXtc M/Gateway post-relační Developments Ltd. Lore Stanford University semi-strukturovaný M/DB:X M/Gateway hierarchický Developments Ltd. MonetDB/XQuery CWI Database Group MonetDB (proprietární) myXMLDB Mladen Adamovic MySQL Natix University of Mannheim proprietární ozone ozone-db.org objektově-orientovaný Sedna ISP RAS MODIS proprietární Timber University of Michigan Shore nebo Berkeley DB Xindice Apache Software proprietární Foundation
20 5 Projekt
Tato kapitola se zabývá vytvořením a otestováním aplikace, která umožní efektivně ukládat a vyhledávat anotované SVG obrázky. První část stanovuje požadavky jak na aplikaci, tak na zvolenou databázi. Druhá část je popisem technologie Enterprise Bean, která je součástí Java 6 Enterprise edice [33,34]. Následuje detailní zpráva o implementaci vytvořené serverové komponenty. Další část se věnuje sestavením dotazů pro vyhledávání v jazyce XQuery, následuje popis vytvořené klientské aplikace. Sekce 5.5 Vybrané nativní XML databáze je soupisem zvolených řešení a jejich nasazení. Na konec je otestována a demonstrována funkčnost aplikace s konkrétní databází.
5.1 Funkční požadavky Účelem projektu je vybrat a implementovat nejvhodnější řešení pro ukládání velkého množství anotovaných SVG obrázků. Vybrané technologie by měly být open source, aby bylo možné zdrojové kódy prohlížet a upravovat. Serverovou aplikaci bude tvořit EJB komponenta, která umožní: • efektivně uložit anotovaný SVG obrázek do databáze • vyhledat obrázky na základě obsahu (tj. obrázky, které mají uvedený požadovaný subjekt ve své anotační části) • vyhledat obrázky na základě ID (obrázky, které mají uvnitř sebe podobjekt s daným ID) Protože komponenta poběží dlouhodobě na aplikačním serveru, je potřeba aby udržovala připojení k databázi. Co se týče formátu návrhu, měla by být dobře strukturovaná, aby její jednoduchou úpravou bylo možné použít jinou databázi. To obnáší vytvořit oddělitelný konektor. Jeho náhradou za jiný bude možné připojit další databázi a přitom nebude potřeba dalších zásahů do kódu aplikace. Jak vyplývá z rozboru SVG obrázku na konci druhé kapitoly v sekci 2.2.2, je třeba zvolit vhodnou databázi. Základním omezením je proto možnost ukládat SVG obrázky stejně efektivně jako XML soubory. Kritická je v tomto směru možnost ukládat tyto nezanedbatelně velké XML soubory buďto s pomocí definice typu dokumentu (DTD) nebo čistě jako XML data. Důležitá je potom možnost zadefinovat použité jmenné prostory. Jinak nelze procházet anotace v části metadat. Databáze musí podporovat dotazovací jazyk XQuery a musí mít vhodné aplikační rozhraní pro připojení v EJB komponentě.
21 5.2 EJB komponenta Enterprise Java Beans (dále jen EJB) jsou řízené serverové komponenty. Umožňují tvorbu modulárních aplikací a jsou součástí platformy Java EE. EJB běží v EJB kontejneru, který je součástí Java EE serveru, jak je znázorněno na následujícím obrázku (Obr. 4). Tento kontejner poskytuje služby na úrovni systému jako jsou např. správa transakcí a bezpečnost. Díky těmto službám lze lehce vytvářet a nasazovat nové komponenty do jádra aplikace.
Obr. 4: Ukázka uspořádání Java EE serveru [35]
Použití EJB technologie je vhodné, pokud má být aplikace škálovatelná a s rostoucím počtem uživatelů je možno ji rozložit na více strojů. Další výhodou je možnost řídit souběžný přístup ke sdíleným objektům ať už použitím synchronizace nebo zamykáním unikátních zdrojů.
22 5.2.1 Druhy EJB EJB se dělí na dva druhy: • Session Bean, která zapouzdřuje tzv. byznys logiku, volitelně může implementovat webovou službu např. pokud je nasazena v prezentační vrstvě aplikace. • Message-driven Bean slouží jako spojení JMS (Java Message Service) [36] s EJB a její pomocí lze obsloužit konkrétní typ zprávy.
Sessin Bean lze ještě dále rozdělit na tři typy: stateless, stateful a singleton.
Stateless Session Bean neudržuje žádný stav relevantní pro komunikaci s klientem, to znamená že jednotlivé požadavky jsou obslouženy bez jakékoli návaznosti na sebe. Každému požadavku je na serveru přiřazena samostatná instance a obsloužení probíhá nezávisle na ostatních úkolech. Tím pádem je tato interakce přirozeně bezpečná. Beany jsou udržovány v tzv. poolu, ze kterého se vybírají pro obsloužení požadavku. Po provedení se do něj vrací. Díky těmto vlastnostem může být obslouženo více klientů a tento typ je vhodnější pro lépe škálovatelné aplikace. Třída reprezentující Stateless Session Bean je anotována: @Stateless. Stateful Session Bean je opakem předchozí bezstavové beany. Proměnné relace mezi klientem a instancí beany jsou označovány jako tzv. konverzační stav (conversational state). Tento stav je uchováván po dobu trvání relace a jakmile klient relaci uzavře, beana zanikne a její obsah (stav) je ztracen. To nepředstavuje problém, protože použité proměnné jsou uchovávány právě jen pro účely této relace. V rámci životního cyklu relace může dojít k pasivaci serverem. Před provedením pasivace zavolá server metodu anotovanou @Prepasivate. Proměnné jsou uloženy a paměť serveru je uvolněna. Pokud není beana po určité době aktivovány (po obnovení je volána metoda s anotací @PostActivate), dochází k jejímu zrušení. Třída reprezentující Stateful Session Bean je anotována: @Stateful. Třetím typem je tzv. Singleton Session Bean. Instance této beany je aktivní po celou dobu běhu aplikace a může existovat pouze jednou. To je výhodné, pokud chceme aby byla jedna instance sdílena pro více klientů. Singleton beany nabízí podobnou funkcionalitu jako bezstavové, ale s tím rozdílem, že obsluhu všech požadavků provádí právě jedna instance této beany namísto tzv. poolu, který udržuje více bezstavových. Stav beany je udržován a přístupný všem klientům. Díky tomu, že Singleton beana běží v průběhu celého životního cyklu aplikace, je užitečné, aby po spuštění provedla počáteční
23 nastavení aplikace (např. připojení k databázi, alokace zdrojů apod.). K tomu slouží anotace @PostConstruct. Při ukončení běhu aplikace beana uvolní zdroje (např. ukončí připojení atd.) použitím metody s anotací @PreDestroy. Třída reprezentující Singleton Session Bean je anotována: @Singleton. Protože tato beana udržuje globálně své stavové proměnné, je potřeba nějakým způsobem řídit přístup k nim. Synchronizovaný přístup může být řízen buďto EJB kontejnerem anotací: @ConcurrencyManagement(CONTAINER) a nebo samotnou beanou anotací: @ConcurrencyManagement(BEAN)
5.2.2 Implementace Serverová aplikace je vytvořena z komponenty, která zpřístupňuje databázi a poskytuje aplikační rozhraní, pomocí kterého bude klient zacházet s SVG obrázky (Obr.5).
Obr. 5: Ukázka hierarchie EJB komponenty Hlavní částí aplikace je AppBean.java třída, která obsahuje všechny potřebné metody používané prezentační vrstvou. Je anotovaná jako @Singleton. To zaručuje, že se v programu její instance vyskytuje právě jednou a běží po celou dobu životního cyklu aplikace. Ve verzi 3.1 dovoluje EJB technologie neuvést třídu rozhraní a to ani lokální ani vzdálené. Takže pokud v budoucnu nebude komponenta integrována do distribuované aplikace,
24 ale poběží zároveň s prezentační částí v jedné „enterprise“ aplikaci, tak tento přístup (no-interface) vyhovuje. Dnešní moderní vývojové nástroje (jako např. Netbeans 7) dokáží vytvořit rozhraní automaticky z veřejných metod, takže v případě potřeby lze doplnit třídu rozhraní takřka bezpracně. Pro úplnost je doplněn alespoň lokální interface (AppBeanLocal.java). Hlavní funkcí této komponenty je vytvoření a kompletace dotazů pro databázi na základě požadavků klientské aplikace. Po spuštění (@PostConstruct) je vytvořena instance queries třídy Queries.java a její pomocí jsou jednotlivým akcím přiřazeny přednastavené dotazy. Předpokládá se nezávislost těchto dotazů na použité databázi, resp. dotazy by měly být univerzální. To bohužel vždy neplatí, proto jsou některé (např. smazání dokumentu) závislé na sadě funkcí, které databáze podporuje. Jak bylo v požadavcích na komponentu uvedeno, je oddělena část připojení od hlavní třídy. Pro vybranou databázi je zvlášť vytvořena třída ConnBean.java, která obsahuje nastavení a specifickou konstrukci pro připojení přes konkrétní API ke konkrétní databázi. Třída je také anotována @Singleton. Její hlavní funkcí je dokončení a provedení dotazu, který ji poslala komponenta AppBean. Lokální rozhraní AppBeanLocal určuje následující metody:
String search(String key, String type) slouží pro vyhledání klíčového slova, typ označuje zda se jedná o hledání v anotacích nebo v polygonech. void upload(String filepath, File file) metoda pro nahrání obrázku do databáze
String download(String uri) metoda pro uložení obrázku z databáze
String showIDs(String uri) metoda zobrazuje všechny ID polygonů, které se v obrázku vyskytují
String showMeta(String uri) metoda zobrazí celou část metadat void changeConnection(String host, int port, String user, String password, String database) pomocí této metody se lze připojit na jinou databázi
String delete(String file) metoda umožňuje smazat obrázek
String info()je metoda pro zobrazení informací o připojené databázi
25 5.3 Sestavení XQuery dotazů Aby bylo možné prohledávat databázi obrázků, je potřeba vytvořit dotazy. Použité XQuery dotazy používají konstrukci FLWOR popsanou v sekci 4.2.2. Aby bylo vůbec možné procházet stromovou strukturu SVG obrázku, je potřeba nejprve uvést použité jmenné prostory, jinak nebude možné interpretovat dotazy. Proto je potřeba před každým dotazem vložit tyto deklarace: declare namespace s = "http://www.w3.org/2000/svg"; declare namespace gate = "http://www.fi.muni.cz/~oslejsek/GATE/gate.owl#"; declare namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"; declare namespace owl="http://www.w3.org/2002/07/owl#"; declare namespace rdfs= "http://www.w3.org/2000/01/rdf-schema#";
Dále je potřeba označit externí proměnné. Nejdříve vložíme databázi (jinak by komponenta byla použitelné pouze pro jednu - přednastavenou). Toho lze docílit dvěma způsoby. Buďto vložíme název databáze přímo do řetězce dotazu: private String database = "myDatabase"; public String getDatabase() { return database; } String myQuery = "for $a in collection('"+getDatabase()+"') . . . Nebo vytvoříme externí proměnnou: String myQuery = " declare variable $database external; " + " for $a in collection($database) . . . A před provedením dotazu svážeme (binding) proměnnou: query.bind("$database", "myDatabase"); return query.execute();
Stejný je postup při označení externí proměnné pro hledané heslo. V projektu je použita u databáze i u hesla druhá varianta. Dále je potřeba procházet stromovou strukturu SVG souboru.
26 5.3.1 Hledání v anotacích Pro hledání v anotacích, které jsou umístěny v části metadata, bylo zvoleno procházení atributů podobjektů grafických objektů označujících složení, jak bylo popsáno v podkapitole 2.3.2.1 např.:
5.3.2 Hledání v polygonech Prohledání polygonů označujících jednotlivé vyznačené objekty je podobné. Nemusí se vždy jednat o polygon (ale např. cesty), ale na věci to nic nemění, protože nás zajímá právě atribut id daného objektu: 27 Výsledný dotaz (bez počátečních deklarací) potom bude vypadat následovně: String polyQuery = "declare variable $key external; for $a in collection('" + getDatabase() + "') where some $p in $a/s:svg/s:g//@id satisfies contains ($p, $key) return base-uri($a)"; 5.4 Klientská aplikace Klientská aplikace, která má za úkol demonstrovat funkčnost EJB komponenty, je vytvořena z jedné JSP stránky. Ta pomocí servletů obsluhuje jednotlivé formuláře [37]. Obr. 6: Ukázka struktury klientské aplikace 5.5 Vybrané nativní XML databáze Technologie nativních XML databází se neustále rozvíjí a díky tomu existuje hned několik kvalitních řešení. V této podkapitole je popsáno, které databáze byly vybrány, jaké mají charakteristiky a jakých výsledků bylo dosaženo. Volbu ovlivňovalo hned několik faktorů. Nejdůležitější bylo, zda má 28 databáze kvalitně popsané zdrojové kódy a zda jsou dostupné a funkční knihovny pro jednotlivá API. Bohužel se nepodařilo připojit všechny databáze a některé se v průběhu implementace ukázaly jako nevhodné nebo nedokončené. Nebylo mým cílem popsat a vyřešit tyto neduhy, ale vyzkoušet nejběžnější a nejznámější NXD. Postup práce byl následující: nalezení poslední stabilní verze, instalace a spuštění. Skoro všechny databáze poskytují možnost vyzkoušet práci s nimi přes příkazový řádek a nebo přes vlastního klienta (např. webového). Další fáze byla vytvoření vzorové databáze a uložení anotovaného obrázku. Poté následoval test připravených XQuery dotazů. Dále byla vytvořena jednoduchá třída s metodou Main, přidány potřebné knihovny a proveden jednoduchý dotaz. To otestovalo možnost připojení v javovém programu. Pak už nic nebránilo tomu vytvořit k databázi ConnBean a vyzkoušet funkčnost v EJB komponentě. Více informací o databázích lze získat z již dříve zmiňovaných stránek Ronalda Bourreta [16] a nebo z bakalářské práce Martina Bukatoviče [38]. Následující podsekce uvádí pouze hlavní charakteristiky, nejedná se tedy o vyčerpávající přehled vlastností jednotlivých databázi. 5.5.1 BaseX BaseX je open source nativní XML databáze, která původně vznikla na německé univerzitě v Kostnici (University of Konstanz) [39]. Je napsána v jazyce Java a k ukládání XML používá vlastní formát. Informace o uzlech XML dokumentu jsou uloženy do souboru tabulek. Dokumenty jsou ukládány do kolekcí (také označovaných jako databáze) a lze je dotazovat pomocí funkcí jazyka XQuery (fn:doc() a fn:collection()). Podporovány jsou čtyři typy indexů. Kromě základních textových a atributových indexů podporuje full- textové, které lze dále nastavit. Posledním typem jsou indexy cest, které slouží k urychlení nalezení umístění uzlu ve stromové struktuře. BaseX lze spustit jako samostatnou aplikaci (databázový server) a nebo v módu klient-server. Z aplikačních rozhraní podporuje: XQJ, XML:DB a pro jazyk Java má vlastní API (BaseXClient.java). BaseX může být spuštěna buďto přes příkazový řádek nebo z přiložené interaktivní aplikace BaseXStudio. Na webových stránkách je přidáno XQuery Live Demo [40], pomocí kterého lze vyzkoušet práci s XQuery dotazy. BaseX podporuje XQuery, XQuery Update Facility a XQuery Full Text. Rozšíření umožňují volat přímo javové funkce a díky podpoře full-text vyhledávání lze provádět dotazy na částečnou shodu (fuzzy). 29 5.5.1.1 Příklad použití vlastního API Tvůrci databáze poskytují vlastní API v jazyce Java. Do projektu je přidána třída BaseXClient.java, která zpřístupňuje databázi. Nejdříve ji vložíme a vytvoříme její instanci. import ejb.BaseXClient; private BaseXClient session; session = new BaseXClient(host, port, user, psswd); Ta se připojí k databázi na uvedené adrese (host, port). Pro dotaz je zde vytvořena vlastní třída: String myQuery = "for $a in collection($database)... "; BaseXClient.Query query = session.query(myQuery); Navážeme proměnné: query.bind("$key", key); query.bind("$database", database); A provedeme dotaz. Výsledkem je řetězec, který lze dále upravovat: String result = query.execute(); 5.5.2 Berkeley DB XML Bekeley DB XML je open source nativní XML databáze, která vznikla jako nástavba nad Berkeley DB [41]. Je vyvíjena společností Oracle (původně Sleepycat Foundation). Dokumenty ukládá do tzv. kontejnerů, na které plní funkci kolekce (databáze). Kontejner je fyzicky uložen jako jeden rozsáhlý soubor, který kromě samotných XML dat obsahuje indexové struktury a metadata. Uživatel může vytvářet vlastní indexy a do databáze lze ukládat i dokumenty v jiném než XML formátu. Berkeley DB XML je pouze knihovna (embeded), kterou lze využít v aplikaci. Nemá proto žádné standardní API, lze ji však použít v mnoha programovacích jazycích. Podporuje XQuery, XQuery Update Facility a poskytuje vlastní API pro aktualizaci dat. 30 5.5.2.1 Příklad použití Následující ukázka kódu demonstruje připojení se k databázi (soubor s koncovkou dbxml). Nejprve importujeme potřebné knihovny: import com.sleepycat.dbxml.*; Vytvoříme instanci třídy XMLmanager a otevřeme kontejner databáze: XmlManager myManager = new XmlManager(); String container = "svgDB.dbxml"; myContainer = myManager.openContainer(container); Potom vytvoříme dotazový výraz: String myQuery = "for $a in ... "; XmlQueryExpression qe = myManager.prepare(myQuery); Provedeme a uložíme výsledky, které pak procházíme. XmlResults results = qe.execute(context); XmlValue value = results.next(); while (value != null) { value.asString(); . . . value = results.next(); } 5.5.3 MonetDB/XQuery MonetDB/XQuery je open source nativní databáze, která vznikla jako rozšíření MonetDB [42]. Pro ukládání XML dat používá vlastní typ binární asociační tabulky (Binary Association Tables). Data jsou zpřístupněna vlastním jazykem (MonetDB Assembly Language), do kterého jsou překládány klasické dotazy v SQL nebo XQuery. Díky tomu je umožněno použít jako API JDBC rozhraní, i když není pro XML databáze vhodný. Dokumenty jsou sdružovány do kolekcí. Každá kolekce má pevně danou množinu tabulek. Kolekce jsou v základu nastaveny jen pro čtení, to umožňuje díky pevně nastavenému seznamu indexů urychlení při dotazování. Součástí databáze je PF/Tijah systém, který umožňuje full-textové vyhledávání. MonetDB/XQuery lze připojit pomocí JDBC, dále je podporováno XRPC. Z dotazovacích jazyků podporuje XQuery, XQuery Update Facility. Vývoj databáze byl ukončen v březnu 2011. 31 5.5.3.1 Příklad použití JDBC V následující ukázce kódu jak lze připojit server MonetDB/XQuery pomocí JDBC. Nejprve je potřeba importovat potřebné knihovny: import nl.cwi.monetdb.jdbc.MonetDriver; import nl.cwi.monetdb.jdbc.*; Zavedeme třídu ovladače: Class.forName("nl.cwi.monetdb.jdbc.MonetDriver"); A vytvoříme připojení. Zde je potřeba u adresy serveru dopsat language=xquery, jinak se JDBC pokusí o interpretaci výstupu. Connection con = DriverManager.getConnection( "jdbc:monetdb://localhost:50000/SVG?language=xquery", "monetdb", "monetdb"); Nyní vytvoříme výraz a provedeme uloženi do Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(...); while ( rs.next() ) { . . . } 5.5.4 Qizx Qizx je komerční nativní XML databáze [43]. Ukládá dokumenty do kolekcí, které mohou být v hierarchii, hlavní kolekce (databáze) je označována jako knihovna. Pro každý dokument jsou zkonstruovány čtyři indexy pro strukturu, textové, atributové a full-textové. Součástí projektu je Qizx Free Engine, který je šířen jako open source, ale je limitován na 1GB dat. Qizx obsahuje vlastní API pro jazyk Java. Podpora XQJ je plánována do budoucna. Podporuje XQuery, XQuery Update Facility a XQuery Full-Text. 5.5.4.1 Příklad použití EJB komponenta udržuje po celý životní cyklus aplikace tzv. LibraryManager. K databázi (zde označované jako knihovna) se připojíme pomocí: private LibraryManager libManager; private File storageDir = new File("C:/QIZX/xdb2"); this.libManager = getLibraryManager(storageDir); 32 Vyhledání dokumentu se provede nad instancí třídy Library. Library lib = getLibrary(this.libManager, "svglibrary"); Dotaz pro vyhledání načteme pomocí přednastavené funkce: String script = loadScript(scriptFile, key); Ta zajistí svázání s hledanou proměnnou key. Ze skriptu pro dotaz je vytvořen výraz, jehož provedením vznikne sekvence výsledků. Přes tu pak můžeme iterovat a upravit formát výstupu např. do řetězce. com.qizx.api.Expression expr = lib.compileExpression(script); ItemSequence results = expr.evaluate(); while (results.moveToNextItem()) { Item result = results.getCurrentItem(); . . . } 5.5.5 Sedna Sedna je volně šiřitelná databáze, kterou vytváří Institut pro systémová programování Ruské akademie věd [43]. Dokumenty jsou uloženy buďto samostatně nebo jako součást jedné kolekce. Databáze poskytuje vlastní rozhraní, dále podporuje XML:DB API a XQJ. Podporuje XQuery a pro aktualizaci používá vlastní jazyk (podobný XQuery Update Facility). 5.5.5.1 Příklad použití XQJ Připojení k serveru Sedna pomocí XQJ je následující. Nejprve, mimo ostatních knihoven, vložíme: import com.xqjapi.sedna.SednaXQDataSource; a vytvoříme tzv. SednaXQDataSource a nastavíme adresu a název databáze: XQDataSource xqs = new SednaXQDataSource(); xqs.setProperty("serverName", "localhost"); xqs.setProperty("databaseName", "test"); Poté se vytvoří připojení do databáze: XQConnection conn = xqs.getConnection("SYSTEM", "MANAGER"); Nyní lze sestaveného dotazu vytvořit výraz: XQPreparedExpression xqpe = conn.prepareExpression("2+3"); 33 a ten následně provést. Vrácenou sekvenci lze procházet: XQResultSequence rs = xqpe.executeQuery(); while(rs.next()) { rs.getItemAsString(); ... } 5.5.5.2 Příklad použití XML:DB API Nejdříve je potřeba naimportovat potřebné knihovny a provedeme registraci ovladače pro přístup k databázi: import org.xmldb.api.*; import org.xmldb.api.base.*; import org.xmldb.api.modules.*; Database dbDriver = (Database) Class.forName( "com.xqjapi.sedna.DatabaseImpl").newInstance(); DatabaseManager.registerDatabase(dbDriver); Načteme kolekci pomocí DatabaseManageru. Collection col = DatabaseManager.getCollection( databaseURI, Username, Password); Vytvoříme službu: XQueryService myService = (XqueryService) col.getService("XQueryService", "1.0"); Provedeme a uložíme výsledek: ResourceSet resourceSet = myService.query(...) Ten pak procházíme pomocí iterátoru: ResourceIterator it= resourceSet.getIterator(); while (it.hasMoreResources()) { Resource res = iterator.nextResource(); res.getContent(); ... } 34 5.5.6 Hodnocení vybraných NXD Všechny vybrané databáze byly bez problémů nainstalovány a spuštěny. Přes příkazový řádek byla vytvořena kolekce SVG obrázků a XQuery dotazy na anotační část i na ID objektů v polygonech fungovaly s výjimkou databáze Sedna. Při pokusu o načtení anotovaného SVG obrázku příkaz vrátil chybu s odůvodněním, že dokument je příliš velký (atribut, který obsahuje vloženou fotografii má velikost kolem 2,3MB) a že byl překročen limit 2MB. Omezení databáze Qizx stanovené na 1GB se nevztahuje čistě na souhrnnou velikost všech obrázků, ale jsou v něm započítané i struktury pro indexy a metadata. Tím pádem při běžné velikosti jednoho anotovaného SVG obrázku bylo tohoto limitu dosazeno už po uložení čtyř set. To je nevyhovující. Databáze MonetDB/XQuery se v komponentě vůbec nepodařilo připojit. Vývoj této databáze byl bohužel momentálně ukončen. Takže novější verzi v dohledné době nelze očekávat. Berkeley DB XML se nepodařilo sprovoznit, protože instanci třídy XmlManager nešlo nastavit jako sdílenou proměnnou komponenty a tím pádem by se musela vytvářet při každé jednotlivé interakci uživatelů s databází. To by při větší zátěži vedlo buďto k chybám nebo zpoždění. Alespoň u BaseX se podařilo zprovoznit vlastní API pro jazyk Java (uvedené v sekci 5.5.1.1). Databáze byla otestována na lokální síti. Více informací popisuje následující podkapitola 5.6. 5.6 Test výsledné aplikace K otestování databáze samotné dodává výrobce vlastního klienta BaseX GUI. Pomocí tohoto programu, který je součástí instalace databáze lze vytvořit a snadno spravovat kolekce dokumentů. Program pohodlně zobrazuje strukturu databáze a hlídá syntaxi XQuery dotazů. Z tohoto programu pochází např. ukázka struktury dat v sekci 2.2.1 (Obr. 3). Tímto programem byly otestovány jednotlivé XQuery dotazy, což značně urychlilo práci. Test uložení anotovaného SVG obrázku proběhl úspěšně. Formulář odešle data do nového okna na Uploadservlet. Ten si zavolá metodu komponenty a předá ji data. Otestování připojení databáze na lokální síti proběhlo následovně. Na počítači s IP: 192.168.1.102 byla nainstalována BaseX databáze. Port, jméno i heslo bylo ponecháno v základním nastavení (admin, admin). Je potřeba se 35 ujistit, že na daném počítači byla databáze spuštěna, stačí spustit z nabídky Start z adresáře BaseX zástupce BaseX Server (Start). Připojení ohlásí změnu databáze (Successfully connected). Otestování prohledání většího počtu obrázků proběhlo následovně. Vloženo bylo 100 obrázků SVG. Celková velikost databáze vzrostla na 272MB, zejména soubor: C:\Program Files\BaseX702\data\DB\atv.basex Rychlost prohledání anotační sekce a polygonů je však kolem jedné sekundy, tedy nebyl pozorován rozdíl. Ten se pravděpodobně projeví až při enormně větší kolekci obrázků. Bohužel z kapacitních důvodů nebyl test tohoto typu proveden. Obr. 7: ukázka webové stránky aplikace 36 5.7 Nastavení a možná rozšíření aplikace Veškeré základní nastavení aplikace je uvedeno v třídě Settings.java. Aplikace si zatím sama neumí vytvořit a spravovat kolekce, proto doporučuji kolekci nejdříve vytvořit v dodaném klientovi BaseX GUI. Aplikace je na míru šita jedné databázi a proto informace o nastavení je potřeba dopsat do zmíněné třídy. Po spuštění si komponenta automaticky vytvoří připojení a umožňuje prezentační vrstvě pracovat s kolekcí dat. Pro účely otestování popsané v předchozí sekci, byla vytvořena metoda reconnect, která umožňuje za běhu aplikace změnit databázi. V praxi doporučuji tuto funkci běžnému uživateli znepřístupnit, protože by tímto kde kdo mohl narušit chod aplikace. Jednou z vad na kráse databáze BaseX je to, že nehlídá duplicitní data. Je proto možné jeden obrázek vložit do databáze vícekrát. Na tento problém navazuje další. Při volání funkce pro vymazání jednoho obrázku, jsou smazány všechny obrázky se stejným názvem. Volaná funkce totiž akceptuje přímo název, přičemž daleko vhodnější by bylo použití URI adresy (původního umístění obrázku). URI adresu obrázku jsem v návrhu používal jako primární klíč, bohužel funkce mazání se tímto neřídí. Očekával jsem, že duplicitní data bude hlídat přímo databáze. Do budoucna proto navrhuji rozšíření o test na duplicitu dat při vkládání. To bohužel zpomalí proces ukládání obrázku. Pro větší přehlednost výpisu do tabulky by se hodilo vytvořit rozšíření o stránkovací funkci. Buďto by se mohlo zobrazovat pouze omezené množství výsledků přímo na straně klienta a nebo je možné upravit XQuery dotazy. Použitím predikátu lze omezit množinu výsledků. declare variable $start:=1; declare variable $end:=10; for $a in collection($DB)[position()=$start to $end] 37 6 Závěr V diplomové práci jsem čtenáře seznámil s grafickým formátem SVG a rozšířením o anotační sekci. Ukázka a rozbor anotovaného obrázku posloužila k ujasnění požadavků na výslednou aplikaci. Dále byly zhodnoceny možnosti uložení XML dokumentů do databází k tomu určených. Pro anotovaný SVG bylo navrženo použití nativní XML databáze (dále NXD), protože jeho obsah je nepravidelný. Ve čtvrté kapitole jsem shrnul základní charakteristiky těchto databází. Popsána byla jednotlivá aplikační rozhraní a podporované jazyky pro práci s XML formátem. V poslední části zmíněné kapitoly uvádím seznam vhodných XML nativních databází, které jsou buďto přímo open source a nebo jsou alespoň nekomerčně použitelné. Bohužel některé z nich mají omezení, která snad překonají další verze. Pátá kapitola se týká hlavní projektové části této práce. Díky zhodnocení předchozích znalostí získaných rozborem anotovaného SVG obrázku, ukládacích technik a vlastností NXD jsem stanovil nejen požadavky na funkcionalitu komponenty ale i na vlastnosti použité databáze. Ze seznamu databází byly proto vybrány čtyři a přidána byla komerční databáze Qizx, která část systému dala volně k dispozici jako open source. To sice přináší omezení velikosti databáze na 1GB, ale i tak přináší zajímavý pohled. Navržená komponenta byla vytvořena jako tzv. singleton. Pro jednoduchost úprav byla vytvořena oddělená třída využívající API každé databáze zvlášť. Díky tomu bylo otestováno několik databází, z nichž se ukázala jako nejvhodnější BaseX. Vytvořené XQuery dotazy se ukázaly jako univerzální, bohužel některé databáze používají pro určité příkazy vlastní funkce (např. mazání dokumentů). Testovací aplikace sloužila pro rychlou vizualizaci výsledků a do budoucna by bylo dobré ji ještě rozšířit o další funkce. Efektivní by jistě bylo vytvářet k obrázkům podobné náhledy, jaké vytváří systém Windows např. u formátu PNG, pro zlepšení přehlednosti práce s obrázky. Stahování celého SVG obrázku je na pomalém připojení k internetu zdlouhavé a náhled by takto ušetřil uživateli čas. Během práce se ukázalo, že některé, v literatuře často uváděné, databáze jsou už jako projekty neaktivní a není tedy do budoucna garantována jejich použitelnost v nových verzích programovacích jazyků. I přes desetiletí vývoje jsou stále nativní XML databáze spíše okrajovou záležitostí a podpora standardů není úplná. Spousta projektů není dokončena a nové standardy se stále utvářejí. 38 Seznam použité iteratury: [1] GATE project. [online]. [cit. 2012-01-09]. Dostupné z: http://lsd.fi.muni.cz/gate/ [2] SVG 1.1 (Second Edition). [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3.org/TR/SVG11/intro.html [3] TIŠNOVSKÝ, Pavel. Vektorový grafický formát SVG. [online]. [cit. 2012-01-09]. Dostupné z: http://www.root.cz/clanky/vektorovy-graficky- format-svg/ [4] Mobile SVG Profiles: SVG Tiny and SVG Basic. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3.org/TR/SVGMobile/ [5] XML DOM Tutorial. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3schools.com/dom/default.asp [6] Tryit Editor v1.5. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3schools.com/svg/tryit.asp?filename=trysvg_myfirst [7] NYKLÍCEK, Jaromír. Anotátor SVG obrázku. Dostupné z: https://is.muni.cz/auth/th/256349/fi_b/thesis.pdf. Bakalářská práce. Masarykova univerzita. Vedoucí práce RNDr. Radek Ošlejšek, Ph.D. [8] MLÝNKOVÁ, Irena. XML technologie: principy a aplikace v praxi. Praha: Grada, 2008. ISBN 978-80-247-2725-7. [9] What is DocBook?. [online]. [cit. 2012-01-09]. Dostupné z: http://www.docbook.org/whatis [10] What is an XML database?. [online]. [cit. 2012-01-09]. Dostupné z: http://xmldb-org.sourceforge.net/faqs.html [11] PCDATA - Parsed Character Data. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3schools.com/xml/xml_cdata.asp [12] XML Information Set (Second Edition). [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3.org/TR/xml-infoset/ [13] SAX 1.0 Overview. [online]. [cit. 2012-01-09]. Dostupné z: http://www.saxproject.org/sax1-roadmap.html [14] XSLT Introduction. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3schools.com/xsl/xsl_intro.asp 39 [15] Get Started with MySQL. [online]. [cit. 2012-01-09]. Dostupné z: http://dev.mysql.com/usingmysql/get_started.html [16] BOURRET, Ronald. Rpbourret.com - XML consulting, writing, and research. [online]. [cit. 2012-01-09]. Dostupné z: http://www.rpbourret.com/ [17] Binary large object. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit.2012-01-09]. Dostupné z: http://en.wikipedia.org/wiki/Binary_large_object [18] Character large object. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2012-01-09]. Dostupné z: http://en.wikipedia.org/wiki/Character_large_object [19] JDBC Overview. [online]. [cit. 2012-01-09]. Dostupné z: http://www.oracle.com/technetwork/java/overview-141217.html [20] API Use Cases. [online]. [cit. 2012-01-09]. Dostupné z: http://xmldb-org.sourceforge.net/xapi/UseCases.html [21] XQJ Tutorial Part I: An XQJ Introduction. [online]. [cit. 2012-01-09]. Dostupné z: http://www.xquery.com/tutorials/xqj_tutorial/intro.html [22] Introducing XQJ: A Java API for XQuery. [online]. [cit. 2012-01-09]. Dostupné z: http://www.devx.com/Java/Article/34642 [23] JSR 225: XQuery API for JavaTM (XQJ). [online]. [cit. 2012-01-09]. Dostupné z: http://www.jcp.org/en/jsr/detail?id=225 [24] Web Services Glossary. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/ [25] XML-RPC. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-[cit. 2012-01-09]. Dostupné z: http://en.wikipedia.org/wiki/XML-RPC [26] SOAP Introduction. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3schools.com/soap/soap_intro.asp [27] Representational state transfer. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2012-01-09]. Dostupné z: http://en.wikipedia.org/wiki/Representational_state_transfer [28] What is WebDAV?. [online]. [cit. 2012-01-09]. Dostupné z: http://www.webdav.org/ [29] Teorie relačních databází: Relační model dat. [online]. [cit. 2012-01-09]. Dostupné z: http://www.manualy.net/article.php?articleID=9 [30] XPath and XQuery Functions and Operators 3.0. [online]. 40 [cit. 2012-01-09]. Dostupné z: http://www.w3.org/TR/xpath-functions-30/ [31] Use XQuery from a Java environment. [online]. [cit. 2012-01-09]. Dostupné z: http://www.xquery.com/tutorials/xquery-java/ [32] XQuery Update Facility 1.0. [online]. [cit. 2012-01-09]. Dostupné z: http://www.w3.org/TR/xquery-update-10/ [33] Java EE at a Glance. [online]. [cit. 2012-01-09]. Dostupné z: http://www.oracle.com/technetwork/java/javaee/overview/index.html [34] Real world Java EE patterns : rethinking best practices. S. l. : Press.adam-bien.com, 2009. ISBN 978-0-557-07832-5. [35] Java EE Containers. [online]. [cit. 2012-01-09]. Dostupné z: http://docs.oracle.com/javaee/6/tutorial/doc/bnabo.html#bnabq [36] Java Message Service. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2012-01-09]. Dostupné z: http://en.wikipedia.org/wiki/Java_Message_Service [37] Core servlets and javaserver pages. Upper Saddle River, N.J. : Prentice-Hall, 2008. ISBN 9780131482609. [38] BUKATOVIČ, Martin. Srovnání dostupných implementací XML databází. Dostupné z: https://is.muni.cz/auth/th/207663/fi_b/bc.pdf. Bakalářská práce. Masarykova univerzita. Vedoucí práce RNDr. Aleš Horák, Ph.D. [39] BaseX. The XML Database. [online]. [cit. 2012-01-09]. Dostupné z: http://basex.org/ [40] XQuery Live Demo. [online]. [cit. 2012-01-09]. Dostupné z: http://basex.org/products/live-demo/ [41] Definitive guide to Berkeley DB XML. Berkeley: Apress, 2006. ISBN 1590596668. [42] Query Processing at Light Speed. [online]. [cit. 2012-01-09]. Dostupné z: http://www.monetdb-xquery.org/ [43]Qizx, a fast XML database engine fully supporting XQuery. [online]. [cit. 2012-01-09]. Dostupné z: http://www.xmlmind.com/qizx/ [44] Sedna XML Database. [online]. [cit. 2012-01-09]. Dostupné z: http://www.sedna.org/ 41 Příloha Obsah přiloženého CD • složka AppBasex obsahuje celý Java EE projekt • elektronická verze diplomové práce ve formátu PDF • složka install obsahuje instalační soubory k databázi • složka jar obsahuje použité knihovny • soubor README.TXT obsahuje popis 42