}w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Personalizace a profilovaní vyhledávání vědeckých publikací DIPLOMOVÁ PRÁCE Bc. Jan Kuběja Brno, podzim 2006
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: Mgr. Jan Pavlovič ii
Poděkování Rád bych poděkoval vedoucímu projektu Mgr. Janu Pavlovičovi za odborné vedení a konzultace při tvorbě této diplomové práce. Dále bych chtěl poděkovat Mgr. Jakubu Ďurovcovi za seznámení s aktuálním stavem a nedostatky vyhledávacího systému před mými úpravami. iii
Shrnutí Obsahem práce je analýza a implementace personalizace a profilování do vyhledávacího systému nad elektronickými zdroji Masarykovy Univerzity. V úvodních kapitolách je popsán vyhledávací systém, jeho stav a funkce před implementací personalizace. V dalších kapitolách bude čtenář seznámen s úpravami, které byly v rámci návrhu implementace na vyhledávacím systému provedeny. Jedná se především o personalizaci, dále potom také o vizualizaci nalezených výsledků, zobrazení postupu při vyhledávání a začlenění nové webové služby, která vrací nalezené výsledky formou XML dokumentu. iv
Klíčová slova Java, vyhledávání, elektronické zdroje MU, webová služba, Internet, vědecké publikace, personalizace, profilování, CCS třídy v
Obsah 1 Úvod............................................. 1 2 Vyhledávací systém vědeckých publikací VEZMU.................. 2 2.1 Architektura systému................................. 2 2.1.1 Uživatelský klient.............................. 2 2.1.2 Klient...................................... 3 2.1.3 Server..................................... 3 2.1.3.1 Downloader............................ 4 2.1.3.2 Cache................................ 4 2.1.4 Plugin..................................... 4 3 Technologie......................................... 7 3.1 Webové služby - Web services............................ 7 3.1.1 SOAP...................................... 8 3.1.2 WSDL..................................... 9 3.1.3 UDDI...................................... 9 3.1.4 Implementace XFire............................. 9 3.1.4.1 Praktický příklad použití z projektu............... 9 3.2 Apache Struts..................................... 11 3.2.1 Konfigurace.................................. 11 4 Personalizace........................................ 13 4.1 Personalizace v digitálních knihovnách...................... 13 4.1.1 Klasifikace metod personalizace...................... 14 4.2 Personalizace vyhledávacího systému....................... 15 4.2.1 Preprocessing dotazu............................ 16 4.2.2 Elektronický zdroj ACM........................... 16 4.2.3 CCS klasifikace................................ 17 4.2.4 Autentizace uživatele vůči INET MUNI.................. 17 4.2.5 Uživatelský profil............................... 18 4.2.5.1 Úložiště profilů........................... 19 5 Vizualizace nalezených výsledků............................ 22 5.1 Postprocessing..................................... 22 5.1.1 Pomocná CCS mapa výsledků....................... 23 5.1.2 CCS strom................................... 24 5.2 Informace o nalezených publikacích........................ 24 5.3 Vizualizace....................................... 24 5.3.1 Textový výpis................................. 25 5.3.2 Grafický výpis................................ 25 6 Zobrazení postupu při vyhledávání........................... 30 6.1 AJAX.......................................... 30 6.2 Implementace u serveru............................... 31 6.3 Implementace u klienta................................ 32 vi
7 Výsledky formou XML.................................. 37 7.1 Rozhraní služby.................................... 38 7.2 Implementace služby................................. 38 7.3 Přidání webové služby do seznamu........................ 39 8 Závěr............................................. 41 Literatura............................................. 43 Rejstřík.............................................. 44 A Obsah přiloženého CD.................................. 45 vii
Kapitola 1 Úvod Tato diplomová práce je primárně zaměřena na to, jak vylepšit stávající vyhledávací systém vědeckých publikací MU z hlediska personalizace a profilování. Tento vyhledávací systém byl původně vyvinut v rámci předmětu PA165 - Vývoj programových systémů v jazyce JAVA jedním z projektových týmů. Systém je funkční a je nasazen v provozu v prostředí univerzity a svou vyhledávací funkci provádí správně. Ovšem časem se zjistilo, že by bylo vhodné jej po několika stránkách vylepšit. Jedná se zejména o nějakou uživatelsky přívětivou prezentaci nalezených výsledků a o personalizaci ve vyhledávání. Stávající systém totiž funguje tak, že na zadaný dotaz odpoví velkým počtem nalezených výsledků, které nejsou žádným způsobem seřazeny a hlavně nejsou žádným standardním způsobem klasifikovány. Tyto problémy by měla tato práce vyřešit. Kromě personalizace a vizualizace výsledků je tato práce ještě o dalších úpravách systému, přesněji jde o zobrazování postupu vyhledávání a o vytvoření webové služby, která poskytuje výsledky formou XML dokumentu. 1
Kapitola 2 Vyhledávací systém vědeckých publikací VEZMU Vyhledávací systém vědeckých publikací VEZMU (Vyhledávač nad Elektronickými Zdroji MU) je projekt který vznikl v rámci předmětu PA165 - vývoj programových systémů v jazyce Java. Jeho hlavní účel byl zapouzdřit různé způsoby vyhledávání nad různými dostupnými elektronickými zdroji do z uživatelského hlediska jediné aplikace, která se uživateli má jevit jako samostatný vyhledávač vědeckých publikací nad několika více dostupnými elektronickými zdroji. Dříve bylo totiž možné vyhledávat pouze nad každým el. zdrojem zvlášt, každý zdroj má své vlastní obecně různé rozhraní k vyhledávání. Dá se tedy říct, že když uživatel chtěl vyhledat maximum publikací, které vyhovují danému dotazu, musel vyhledávat nad každým zdrojem zvlášt, což je pochopitelně zdlouhavé a nepříjemné. 2.1 Architektura systému Celý systém je navržen jako několik webových aplikací, které mezi sebou komunikují prostřednictvím webových služeb. Jedná se tedy o servisně orientovanou architekturu (SOA). Systém je tedy navržen poměrně hodně modulárně, což má za následek několik výhod, zejména to, že každý z modulů může fungovat samostatně na jiném servlet containeru či aplikačním serveru. Každý modul v sobě zapouzdřuje svou funkcionalitu, kterou ostatním komponentám poskytuje prostřednictvím definovaného rozhraní. Komponenty mezi sebou komunikují pomocí SOAP protokolu, ovšem systém s uživatelem resp. uživatelskou aplikací či klientem komunikuje prostřednictvím protokolu HTTP. Na obrázku je zakreslena architektura systému. Jednotlivé součásti budou dále podrobněji rozebrány. 2.1.1 Uživatelský klient Pod pojmem uživatelský klient mějme na mysli klientskou aplikaci či obecně přístroj, který přistupuje k vyhledávání jakožto k celému systému. Tato komponenta tedy není součástí vyhledávacího systému, ale je potřeba ji zde také uvést. Typicky se tedy jedná o nějaký webový prohlížeč na straně uživatele, který vidí celý systém pouze jako jednu velkou serverovou aplikaci. Tímto uživatelským klientem ovšem může být cokoliv dalšího, co je schopné komunikovat s vyhledávacím systémem prostřednictvím HTTP protokolu. Může to tedy být i nějaká jiná aplikace nebo také nějaký jiný webový prohlížeč v PDA přístrojích. 2
2.1. ARCHITEKTURA SYSTÉMU Obrázek 2.1: Architektura systému, zdroj: Jakub Ďurovec - Komponentová zapouzdřenost webových aplikací 2.1.2 Klient Klient je webová aplikace, která slouží jako rozhraní systému s uživatelem nebo chceme-li s uživ. klientem. Uživatel vidí pouze tuto aplikaci, zde zadává vyhledávací dotaz a poté je zde seznámen s výsledky vyhledávání. Tato aplikace je navržena s využitím možností aplikačního rámce Apache Struts, který slouží k vývoji web. aplikací tak, že plně podporuje model architektury MVC (Model View Controller). K provozu této aplikace stačí jednoduchý servlet container jako je např. Apache Tomcat. 2.1.3 Server Server je jádrem systému. Přeposílá vyhledávací dotaz zadaným elektronickým zdrojům (přesněji jejich pluginům) a dále shromažd uje výsledky vyhledávání a potom je odesílá WS klientovi. Server nerozlišuje typy dotazů, neví jak se nad kterým elektronickým zdrojem vyhledává. Při přijetí dotazu od klienta s si z něj zjistí, ve kterých el. zdrojích se má dále vyhledávat a na ty tento dotaz odešle a čeká na výsledky. K provozu této aplikace stačí též 3
2.1. ARCHITEKTURA SYSTÉMU Obrázek 2.2: Aplikace Klient jednoduchý servlet container jako je např. Apache Tomcat. Když se podíváme na informační JSP stránku serveru, vypíše se několik informací, zejména zde vidíme seznam vyhledávacích pluginů, které server v aktuální konfiguraci může využívat na vyhledávání. 2.1.3.1 Downloader Aplikace server dále funguje jako Downloader - přesněji ze všech nalezených publikací vybere několik prvních (dle nastavení) z nich a dané publikace se pokusí stáhnout ze vzdálené elektronické knihovny k sobě do své databáze. 2.1.3.2 Cache Server má k dispozici svoji cache. Uchovává si historii dotazů kladených na systém a jejich nalezené výsledky, aby pro následující stejný dotaz nemusel systém vyhledávat stejné publikace znovu. Takže prakticky to funguje tak, že přijde-li na server vyhledávací dotaz, tak se nejdříve prohledá cache, zda-li nebyl náhodou tento dotaz už v poslední době zpracován. Když ano, výsledky se načtou z cache, když ne, tak se pokračuje ve standardním vyhledávacím postupu. Tato cache je realizována pomocí databáze PostgreSQL a aplikace s ní komunikuje pomocí JDBC. 2.1.4 Plugin Systém má k dispozici několik elektronických zdrojů nad kterými vyhledává. Ovšem tyto zdroje jsou obecně různé, přesněji komunikace s nimi je obecně různá. Proto je systém dále navržen tak, že s těmito zdroji nekomunikuje hlavní komponenta server, nýbrž speciální pluginy. Plugin má za úkol převzít od serveru dotaz ve standardní jednotné formě (přesněji objekt třídy, která implementuje rozhraní standardního vyhl. dotazu), a podle tohoto dotazu 4
2.1. ARCHITEKTURA SYSTÉMU Obrázek 2.3: Aplikace Server se patřičně dotazuje na jeden svůj konkrétní elektronický zdroj. Tedy každý plugin umí vyhledávat ve svém el. zdroji a také z něj číst výsledky vyhledávání. Tyto výsledky se opět převedou do jisté standardní formy srozumetelné pro server a vrátí se serveru, který je takto začně sbírat od všech požadovaných vyhledávacích pluginů, které se této jedné vyhledávací akce zúčastnily. Na počátku implementace systému byly k dispozici čtyři elektronické zdroje. V průběhu dalšího vylepšování systému jich přibývalo. V současné době je jich šest a mám informace, že se plánuje začlenění dalších dvou el. zdrojů. Současné elektronické zdroje jsou uvedeny v seznamu níže. Nature - Nature DLhttp://www.nature.com 5
2.1. ARCHITEKTURA SYSTÉMU ACM - Association for Computing Machinery DL, http://www.nature.com IEEE - IEEE computer society DL, http://www.computer.org/portal/site/csdl/ DocBook - DocBook DL, http://www.docbook.org/search/ Link - Springer Link DL, http://www.springerlink.com/ Oxford-Ref - Oxford Reference Online, http://www.oxfordreference.com/ Pluginů je tedy v systému několik, každý z nich je jedna webová aplikace. K provozu každé této aplikace stačí též jednoduchý servlet container jako je např. Apache Tomcat. 6
Kapitola 3 Technologie Dříve než se budeme podrobněji zabývat úpravami celého vyhledávacího systému, seznámíme se s několika zásadními technologiemi, na kterých je projekt postaven. Jedná se tedy především o: Web Services - webové služby, slouží ke komunikaci mezi komponentami systému Apache Struts - open-source framework pro tvorbu webových aplikací dle modelu MVC 3.1 Webové služby - Web services Webové služby představují standardizované rozhraní pro komunikaci a přenos dat mezi různorodými aplikacemi, které mohou běžet na obecně různých operačních systémech. Jsou založeny na mnoha dalších technologiích a standardech. Nahrazují dřívější způsob komunikace přes HTTP protokol pomocí metod GET a POST. Původně fungovala komunikace mezi dvěma aplikacemi často tak, že klient zaslal HTTP požadavek na server a to použitím metody GET či POST, které umožňují v rámci tohoto požadavku zaslat i požadovaná data. Server požadavek přijal, data zpracoval a výsledek zaslal klientovi jako HTTP odpověd. Tento způsob komunikace ovšem skrývá několik nevýhod, zejména fakt, že přenášená binární data jsou závislá na architektuře či operačním systému. A jak se data budou posílat nebylo nikde řečeno. Webové služby mají standardizovaný způsob přenosu dat, díky kterému se vyhneme tomuto problému. Využívá jazyka XML, který je vhodný pro přenos různých textových dat, ale také i složitějších datových struktur. Webové služby využívají těchto standardů: SOAP WSDL UDDI 7
3.1. WEBOVÉ SLUŽBY - WEB SERVICES Obrázek 3.1: Schéma komunikace a standardů webových služeb, zdroj: Wikipedia - http://en.wikipedia.org/wiki/web_service 3.1.1 SOAP SOAP (Simple Object Access Protocol) je protokol pro zasílání zpráv obvykle přes HTTP protokol. Definuje rozšiřitelný formát zpráv mezi klientem a serverem založený na XML. Tedy cokoliv se odesílá, musí se převést do tohoto formátu. Textová data nejsou problémem, ale v případě dat binárních je ještě nutné je zakódovat pomocí kódování BASE64. Toto kódování a následné dekódování s sebou ovšem nese nějakou časovou náročnost. Zde je uveden příklad SOAP zprávy, kterou vygeneroval klient a zasílá ji serveru: <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <getproductdetails xmlns="http://warehouse.example.com/ws"> <productid>827635</productid> </getproductdetails> </soap:body> </soap:envelope> A tady je SOAP odpověd na požadavek od klieta: <soap:envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <getproductdetailsresponse xmlns="http://warehouse.example.com/ws"> <getproductdetailsresult> <productname>toptimate 3-Piece Set</productName> <productid>827635</productid> 8
3.1. WEBOVÉ SLUŽBY - WEB SERVICES <description>3-piece luggage set. Black Polyester. </description> <price>96.50</price> <instock>true</instock> </getproductdetailsresult> </getproductdetailsresponse> </soap:body> </soap:envelope> 3.1.2 WSDL WSDL (Web Services Description Language) je XML formát pro popis webových služeb. Definuje způsob, jak lze volat danou vebovou službu a jakým způsobem se pak vrací výsledek. Díky tomuto popisu si může klient nejprve zjistit, jaké služby nabízí server. V tomto popisu jsou také začleněny formáty různých složitějších datových struktur formou XML schématu. Na základě WSDL popisu může klient sestavit SOAP požadavek. 3.1.3 UDDI UDDI (Universal Description, Discovery, and Integration) je další ze základních standardů pro webové služby. Je to veřejný registr, uchovává informace o webových službách a jejich poskytovatelích ve formátu XML. Registr je přístupný prostřednictvím své webové služby, tedy pomocí protokolu SOAP. 3.1.4 Implementace XFire V tomto projektu byla zpočátku používána pro webové služby implementace Apache Axis. Nicméně vývojáři časem zjistili, že to s sebou nese několik problémů např. časová náročnost, absence podpory Javy 5. Potom bylo rozhodnuto přepracovat projekt tak, aby se používala implementace webových služeb XFire, která řeší všechny výše uvedené problémy a navíc programování komunikace je jednodušší. 3.1.4.1 Praktický příklad použití z projektu Nyní si popíšeme, jak vypadá komunikace mezi klientem a serverem pomocí webové služby, konkrétně implementace XFire. Je potřeba provést následující kroky: Na straně serveru vytvořit rozhraní služby a třídu, která jej implementuje Nakonfigurovat server XFire aplikaci Implementovat klienta 9
3.1. WEBOVÉ SLUŽBY - WEB SERVICES Na straně serveru tedy máme rozhraní SearchService, které specifikuje dvě metody s názvem processquery: package cz.muni.fi.vezmu; import java.util.vector; public interface SearchService{ public Vector<Metadata> processquery (Query query) throws SearchException; public Vector<Metadata> processquery (String query) throws SearchException; } Dále na straně serveru máme třídu Server, která toto rozhraní implementuje. Nyní je potřeba ještě nějak dát rámci XFire na vědomí, že je zde tato služba k dispozici. V adresáři webové aplikace se vytvoří soubor META-INF/xfire/services.xml, který slouží k popisu jednotlivých webových služeb. Popis naší konkrétní služby je následující: <beans xmlns="http://xfire.codehaus.org/config/1.0"> <service> <name>vezmuservice</name> <namespace>cz.muni.fi.vezmu</namespace> <serviceclass>cz.muni.fi.vezmu.searchservice</serviceclass> <implementationclass>cz.muni.fi.vezmu.server.server</implementationclass> </service> </beans> Ještě je potřeba v aplikační konfiguračním souboru web.xml nadefinovat XFireServlet a jeho URL: <servlet> <servlet-name>xfireservlet</servlet-name> <display-name>xfire Servlet</display-name> <servlet-class> org.codehaus.xfire.transport.http.xfireconfigurableservlet </servlet-class> </servlet> <servlet-mapping> <servlet-name>xfireservlet</servlet-name> <url-pattern>/servlet/xfireservlet/*</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>xfireservlet</servlet-name> <url-pattern>/services/*</url-pattern> </servlet-mapping> V tuto chvíli je webová služba na straně serveru prakticky připravena k použití. Její WSDL popis můžeme získat pomocí XFireServletu při HTTP GET dotazu na URL 10
http://localhost:8084/vezmu-server/services/vezmuservice?wsdl 3.2. APACHE STRUTS kde http://localhost:8084/vezmu-server/ je URL, kde je aplikace v tuto chvíli nasazena. Na straně klienta je potřeba provést požadavek na tuto službu, což je v případě použití rámce XFire docela jednoduché:... //Define service URL String serviceurl = "http://localhost:8084/vezmu-server/" ; //Create a metadata of the service Service servicemodel=new ObjectServiceFactory().create(SearchService.class); //Create a proxy for the deployed service XFire xfire = XFireFactory.newInstance().getXFire(); XFireProxyFactory factory = new XFireProxyFactory(xfire); SearchService client = null; try{ client = (SearchService) factory.create(servicemodel, serviceurl); }catch (MalformedURLException ex) { throw new SearchException("Malformed web-service URL", ex); } //Invoke the service Vector<Metadata> serviceresponse = null; serviceresponse = client.processquery(query);... 3.2 Apache Struts Struts je jedním z frameworků pro tvorbu webových aplikací, který dodržuje architekturu MVC (Model View Controller). Tento model vznikl z toho důvodu, že se často programují webové aplikace poměrně chaoticky, tedy např. do JSP stránek se vkládají kusy databázových kódů či kód, který zpracovává data odeslaná z předchozí stránky a podobně. MVC model rozděluje celý kód aplikace na tři části. Model reprezentuje datovou vrstvu, View reprezentuje design web. stránek, Controller reprezentuje navigační záležitosti aplikace, stará se o data zadaná uživatelem a volá datovou vrstvu. 3.2.1 Konfigurace Konfigurace rámce Struts se provádí v souboru struts-config.xml. Nastavuje se zde vše co tento rámec nabízí: Form Beans - formulářové beany Global Exceptions - globální vyjímky 11
3.2. APACHE STRUTS Global Forwards - globální přesměrování Action Mappings - mapování akcí na URL Message Resources - zdroje pro texty a zprávy v aplikaci a další Nejvýznamějším nastavením jsou definice akcí a jejich mapování na URL. Z těchto definic lze pak krásně vidět, jak aplikace pracuje a jak probíhá interakce s uživatelem. Zde je uvedena jedna z akcí aplikace klient vyhledávacího systému: <action path="/search.setsource" name="queryform" scope="session" validate="true" parameter="setsource" input="/pages/source.jsp"> type="cz.muni.fi.vezmu.client.queryaction" <forward name="default" path="/pages/advancedquery.jsp"/> </action> Tato akce ja definována tak, že ji rámec Struts spustí, když přijde požadavek na URL /Search.setSource. Tato akce má k sobě asociován form-bean queryform, který je umístěn v oblasti session. Formulářová data se mají validovat, a když se při validaci vyskytne chyba, řízení se vrátí na stránku /pages/source.jsp. Je-li validace bez chyb, řízení se předá třídě cz.muni.fi.vezmu.client.queryaction resp. její metodě execute, která vrací výsledek jako objekt třídy ActionForward. Zde se nabízí k použití forward default, který předá řízení JSP stránce /pages/advancedquery.jsp. 12
Kapitola 4 Personalizace Personalizace elektronických knihoven snižuje rozdíl mezi tím, co všechno může knihovna uživateli nabídnout a tím, co je skutečně potřeba v této knihovně najít. Vzhledem k tomu, že každá skupina uživatelů vyžaduje jiné typy informací, hraje personalizace významnou roli v jejich vyhledávání. Hlavním přínosem personalizace je předvýběr obsahu, strukturování obsahu v závislosti na dané specifické doméně a obohacení obsahu o metadata. 4.1 Personalizace v digitálních knihovnách Digitální knihovna je prostředníkem mezi uživatelem resp. jeho informačními potřebami a mezi globálně dostupným obsahem informací. Její funkcionalita se dá rozdělit do čtyř následujících funkcí. Předvýběr obsahu (content pre-selection) - knihovna vybere kvalitní obsah potenciálně relevantní pro danou zájmovou skupinu uživatelů Strukturování obsahu (content structuring) - knihovna vytváří strukturu obsahu dle významných domén zájmových skupin uživatelů. Obohacení obsahu (content enrichment) - knihovna obohacuje objekty obsahu popisujícímy metadaty Knihovní služby (library services) - služby pro získání obsahu, pro přístup a pro podporu identifikace relevantních materiálů. Přestože tyto čtyři techniky umožňují digitálním knihovnám výrazně zmenšit rozdíl mezi hojným a různorodým obsahem a specifickými informačními potřebami konkrétních uživatelských komunit, stále je zde jistý nedostatek v tom, že obsah a služby jsou nabízeny komunitě jakožto celku. Informační potřeby jednotlivců či menších skupin uživatelů jsou určeny různými faktory, které jsou celkově nazývány jako kontext použití (context-of-use). Mimoto individuální konceptualizace informačního spektra, které se obecně u každého uživatele liší ovlivňuje individuální přístup. Tedy personalizace u digitálních knihoven představuje i to, že knihovny v závislosti na kontextu použití nabízí jednotlivcům specifický pohled na obsah, místo jednotného pohledu pro celou komunitu. 13
4.1. PERSONALIZACE V DIGITÁLNÍCH KNIHOVNÁCH Obrázek 4.1: Digitální knihovna jako prostředník mezi obsahem a komunitou uživatelů, zdroj: Erich Neuhold - Personalization in Digital Libraries An extended view 4.1.1 Klasifikace metod personalizace Na základě výše uvedeného netriviálního pohledu na personalizaci v digitálních knihovnách mohou být metody personalizace klasifikovány dle obrázku 4.2. Na nejvyšší úrovni máme personalizaci v digitálních knihovnách, u které dále rozlišujeme metody, které se odkazují na služby knihovny a metody, které se odkazují na obsah knihovny. U personalizace služeb knihovny dále rozlišujeme služby pro podporu personalizace jako např. individuální notifikace a personalizaci vlastností služeb jako např. personalizovaná vizualizace, individuální nastavení služeb a podobně. Personalizace obsahu je rozdělena na tři části. Personalizace pomocí obohacování informací (content enrichment), personalizace pomocí výběru obsahu (content selection) a personalizace pomocí individuálního strukturování obsahu (content structuring). V případě obohacování informací jsou k usnadnění individuálních rozhodnutí poskytována dodatečná metadata. To mohou být komentáře expertů dané domény, různá doporučení získaná na základě podobností uživatelských preferencí a jiných typů anotací. Personalizace pomocí výběru obsahu obsahuje metody, které používají filtrování informací na základě uživatelských preferencí. Většina těchto 14
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Obrázek 4.2: Klasifikace metod personalizace, zdroj: Erich Neuhold - Personalization in Digital Libraries An extended view metod je založena na modelování charakteru uživatele např. oblast zájmu uživatele. Metody získávají tato data sledováním chování uživatele. Jednoduchá forma personalizace pomocí strukturování obsahu je poskytnutí dodatečných vstupních bodů (entry points) k nabídce dané informace v digitální knihovně. Další formou mohou výt navigační zkratky - dodatečné navigační struktury, které jsou vytvářeny na základě frekvence navigací použitých uživatelem. 4.2 Personalizace vyhledávacího systému Některé zájmové skupiny uživatelů či přímo někteří uživatelé by rádi očekávali od systému takovou vlastnost, že bude při vyhledávání brát na zřetel i jejich implicitní předem definované parametry např. vědní oblast, minimální a maximální rok vydání publikace a podobně. Vyhledávací systém je totiž navržen tak, že vrací poměrně velké množství dokumentů bez ohledu na to, v jaké míře jsou k dotazu relevantní. Vznikl tedy požadavek, aby byl vyhledávací systém patřičně přepracován a aby do něj byla implementována v jisté míře personalizace. Původně systém totiž uměl vyhledávat maximálně podle několika málo vstupních údajů: Vlastní dotaz Autor Název publikace 15
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Minimální datum vydání Maximální datum vydání Klíčová slova Velikost seznamu výsledků Preferovaný jazyk Těchto parametrů není mnoho, ale hlavně mezi nimi není žádný takový, který by nějakým způsobem reprezentoval příslušnost k nějaké konkrétní vědní oblasti. Dále systém nerozlišuje uživatele. Uživatel se prostě dostane na vyhledávací formulář, zadá některá z těchto mála kritérií a spustí vyhledávání. Chce-li poté vyhledávat znovu, vrátí se na zmíněný formulář a nezbývá mu nic jiného než zadat dotaz znovu, i když má uživatel na mysli dotaz docela podobný tomu předchozímu. Stručně řečeno, neprobíhá zde žádná personalizace, žádná autentizace, systém se ke všem uživatelům chová stejně. 4.2.1 Preprocessing dotazu Chceme systém vylepšit. Jedno z vylepšení spočívá v preprocessingu nebo-li předzpracování dotazu v závislosti na daném uživateli, který dotaz zadal. Stávající vyhledávací systém totiž nic takového neumožňuje, pracuje dle activity diagramu, který je znázorněn na obrázku 4.3. My potřebujeme totiž ještě před zahájením vyhledávání provést nějaké vhodné zpracování dotazu, obohacení dotazu v závislosti na konkrétním uživateli. Je tedy potřeba si někde pamatovat seznam výchozích vyhledávacích parametrů uživatele a před vlastním vyhledáváním tyto parametry spolu se zadaným dotazem nějakým způsobem spojit v jeden nový dotaz, který bude dále vyslán serveru k vyhledávání. Systém by mohl vypadat následujícím způsobem, který je znázorněn activity diagramem na obrázku 4.4. Postprocessing a výpisy výsledků dle CCS klasifikace jsou předmětem další kapitoly, tyto části procesu vyhledávání jsou zde uvedeny jen pro úplnost. 4.2.2 Elektronický zdroj ACM Vyhledávací systém má k dispozici několik elektronických zdrojů. Jedním z nich je digitální knihovna ACM. Právě s ohledem na vlastnosti této knihovny bude do systému zapracována personalizace. Nabízí totiž velké množství vstupních parametrů k vyhledávání, ale hlavně umí vyhledávat dle CCS klasifikace, což je velmi důležitý poznatek. Tato digitální knihovna poskytuje jednoduché a rozšířené vyhledávání. Vyhledávací systém využívá rozšířené vyhledávání. 16
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Obrázek 4.3: Activity diagram procesu vyhledávání stávajícího systému z hlediska zpracování dotazu 4.2.3 CCS klasifikace CCS (Computing Classification System) je obecná klasifikace vědních oblastí a jejich podoblastí v rámci oboru IT. Je to hierarchie tříd, každá třída reprezentuje jistou oblast zájmu. Každá třída má svůj kód, tyto kódy dodržují jistou tečkovou notaci. Tedy např. třída B.4.2 - Input/Output Devices reprezentuje oblast, která patří do oblasti B.4 - INPUT/OUTPUT AND DATA COMMUNICATIONS a též do oblasti B.- Hardware. Část výpisu hierarchie je zobrazena na obrázku 4.5. 4.2.4 Autentizace uživatele vůči INET MUNI Aby systém mohl vůbec personalizaci provádět, musí umět nějakým způsobem rozlišovat a identifikovat uživatele, kteří s ním pracují. Na snadě je tedy uživatele autentizovat. Autentizaci provádí INET MUNI pomocí Basic autentizace. Chce-li uživatel pracovat s částí vyhledávacího systému, kde se uplatňuje personalizace, je nejdříve vyzván, aby zadal své přihlašovací jméno a heslo platné v rámci INET MUNI. Proběhne-li autentizace úspěšně, řízení je opět předáno vyhledávacímu systému. Ten si ještě uloží identifikaci přihlášeného uživatele a dále může s uživatelem pracovat. 17
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Obrázek 4.4: Požadovaný activity diagram procesu vyhledávání 4.2.5 Uživatelský profil Každý uživatel má v autentizované části systému svůj profil. Tento profil v praxi znamená přednastavené hodnoty parametrů pro vyhledávání. Navíc těchto parametrů je zde podstatně více než v běžném formuláři pro pokročilé vyhledávání a zejména je tu parametr CCS klasifikace, který je jedním z nejvýznamějších podnětů, a na kterém vůbec myšlenka profilování a personalizace vyhledávacího systému vznikla. Tento profil se chová tak, že po přihlášení uživatele si načte jeho formulářové parametry z databáze a předvyplní je do formuláře. Uživatel tak může mít trvale nastavena jistá vyhledávací kritéria. Do formuláře může zadat další explicitní parametry. Formulář má dole vedle odesílacího tlačítka Search ještě zaškrtávací pole Save, které bývá implicitně zaškrtnuto. To znamená, že formulář, tak jak byl odeslán k vyhledávání publikací, se uloží uživateli do profilu. 18
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Obrázek 4.5: Část výpisu hierarchie CCS tříd, zdroj: ACM DL - http://www.acm.org/class/1998/ccs98.html 4.2.5.1 Úložiště profilů Informace z uživatelských profilů je potřeba někam trvale uložit. Nejlepší volbou v této situaci je pochopitelně databáze. Dokonce nám nic nebrání použít stejný databázový stroj, jaký používá komponenta server při cachování, tedy databázi PostgreSQL. V této databázi již máme několik tabulek pro provoz cachování pro server, ale vůbec nevadí, když bude naše úložiště právě zde. Na obrázku 4.7 je uveden ERD diagram databáze, kde entita profile tvoří úložiště informací o profilu uživatele. 19
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Obrázek 4.6: ACM uživatelský profil 20
4.2. PERSONALIZACE VYHLEDÁVACÍHO SYSTÉMU Obrázek 4.7: ERD diagram vyhledávacího systému 21
Kapitola 5 Vizualizace nalezených výsledků Vyhledávací systém po zadání dotazu vrací uživateli seznam výsledků. Jedná se o popisy nalezených publikace. Samotné publikace lze stáhnout až kliknutím na odkaz na příslušnou publikaci. Výsledek se tedy skládá z několika informací popisujících vlastní dokument, přičemž některé z těchto informací jsou základní a jsou k dispozici u každého výsledku a ostatní informace o výsledku jsou dodatečné, nepovinné. Povinné informace jsou v následujícím seznamu: Název publikace Autor či autoři Vydavatel Datum vydání URL odkaz na vlastní publikaci Dodatečné informace do výsledku zapisuje komponenta plugin v závislosti na tom, o jaký elektronický zdroj se jedná, protože každý el. zdroj poskytuje různé informace o svých výsledcích. Ovšem informace, které jsou poskytovány všemi el. zdroji jsou brány jakožto základní. Problém je ovšem v tom, že výsledek vyhledávání je pro uživatele jen holý seznam výsledků, nic víc. Tento seznam není podle žádného kritéria seřazen, není nijak kategorizován, výsledky nejsou žádným způsobem klasifikovány. Ovšem my bychom potřebovali provést po vyhledání výsledků nějaký postprocessing, na základě kterého bychom potom mohli výsledky nějakým způsobem setřídit nebo kategorizovat. Chtěli bychom, aby systém vypadal asi tak, jak je uvedeno na obrázku 4.4 předchozí kapitoly. 5.1 Postprocessing Postprocessing nebo-li zpracování výsledků po vyhledávání se provádí na straně klienta. Jeho průběh je znázorněn na activity diagramu na obrázku 5.1. 22
5.1. POSTPROCESSING Obrázek 5.1: Activity diagram postprocessingu 5.1.1 Pomocná CCS mapa výsledků Postprocessing je navržen tak, že při finálním výpisu výsledků dle CCS stromu se musí v daný okamžik nějak zjistit, které všechny výsledky patří do dané CCS třídy. Šlo by to sice provádět nějakým iteračním cyklem přes všechny výsledky, ale toto řešení by bylo poměrně neefektivní. Je lepší, když si systém hned na počátku zpracování výsledků vytvoří tzv. CCS mapu výsledků, pomocí které si bude mapovat CCS třídu na seznam výsledků, které do ní patří. Toto řešení bude efektivnější a tedy i rychlejší a navíc se dá později vytvořená CCS mapa využít i k dalším případným vylepšováním systému. Využijeme toho, že po získání výsledků od serveru si klient všechny výsledky postupně projde, přesněji prochází se seznam výsledků od serveru a tvoří se nový seznam výsledků v podobě jiných objektů, se kterými umí klient lépe pracovat. V rámci tohoto procházení se číslo výsledku patřičným způsobem zapíše do CCS mapy. Tato mapa má v sobě tři základní privátní objekty: private HashMap<String, List<Integer> > primarymap ; private HashMap<String, List<Integer> > additionalmap ; private List<Integer> unclassifiedlist ; Mapa primarymap mapuje kód CCS třídy na seznam čísel výsledků, které mají tuto CCS třídu jakožto primární klasifikaci. Mapa additionalmap mapuje kód CCS třídy na seznam čísel výsledků, které mají tuto CCS třídu jakožto dodatečnou klasifikaci. Každý výsledek je bud klasifikován nebo neklasifikován. Je-li neklasifikován, pak nepatří do žádné z map, patří do seznamu neklasifikovaných výsledků, tedy do seznamu unclassifiedlist. Je-li výsledek klasifikován, je zařazen do mapy primárních klasifikací dle své klasifikace, má-li dále ještě nějaké dodatečné klasifikace, je také patřičně zařazen do mapy dodatečných klasifikací. 23
5.2. INFORMACE O NALEZENÝCH PUBLIKACÍCH 5.1.2 CCS strom Je potřeba, aby systém znal strukturu CCS stromu, protože právě podle tohoto stromu se provádí výpis seznamu výsledků. Tato struktura je dána XML souborem. My ovšem potřebujeme na procházení tohoto stromu nějaký lepší mechanismus objekt org.w3.dom.document, který bychom jednoduše vytvořili na základě tohoto souboru. Pro procházení CCS stromu při výpisu výsledků bude vhodnější struktura jiná, protože XML soubor obsahuje daleko více informací než je k tomuto úkolu potřeba a tudíž je poměrně velký. Na práci se strukturou CCS stromu byla navržena třída CCSTree, která reprezentuje strom a každý jeho list je objekt třídy CCSNode. Třída CCSTree je singleton tj. budeme používat pouze jedinou její instanci. To proto, protože v konstruktoru se provádí načítání dat z XML souboru a konstrukce vlastního podstromu a navíc není důvod, aby se to provádělo opakovaně. 5.2 Informace o nalezených publikacích Když se podíváme na obrázek 5.1 a zaměříme na proces Vyhledávání výsledků tak zjistíme, že pod tímto procesem se skrývá několik dalších akcí, které musí server zajistit: Zjistit z dotazu seznam elektronických zdrojů, které se mají použít Poslat dotaz všem příslušným pluginům Zadat dotaz a získat výsledky - provádí každý z pluginů Shromáždit výsledky od všech pluginů do jednoho seznamu Informace o nalezených publikacích tedy získávají až příslušné pluginy. Žádná jiná komponenta systému žádné další informace nepřidává. My ovšem chceme, aby se seznam výsledků dal podle něčeho klasifikovat, ale žádná ze stávajících informací o výsledku nám to neumožňuje. Cílem tedy je alespoň u zdroje ACM získat ještě informaci o CCS klasifikaci výsledku, aby se dal potom výpis výsledků nějakým způsobem zakreslit do hierarchie CCS tříd. Ovšem aby se získala CCS informace o výsledku, bylo třeba trochu přepracovat ACM Plugin, protože ten tuto informaci neposkytoval. Tato úprava prakticky znamená to, že ACM Plugin vyšle na svůj elektronický zdroj více HTTP požadavků, což v jisté míře zpomaluje celý vyhledávací proces, ale výhodou je, že pomocí CCS informace o výsledcích můžeme následně v klientovi provést nějaký speciální výpis výsledků dle CCS klasifikace a dále tato informace může sloužit k dalším účelům či úpravám systému. 5.3 Vizualizace Jsme již ve fázi, kdy máme k dispozici informace o CCS třídách jednotliových výsledků. Díky výše uvedeným připraveným strukturám - CCS mapa a CCS strom můžeme nyní začít s vlastní vizualizací výsledků. Máme několik možností jak vizualizaci implementovat: 24
5.3. VIZUALIZACE Textově Graficky Pomocí jiných technologií s tím, že by se musel značně přepracovat klient Nejprve byl zvolen textový způsob. Provedla se implementace a vypadalo to zpočátku jako postačující řešení. Ale později vznikl požadavek výpis výsledků pokud možno nějakým způsobem lépe zvizualizovat. Byl tedy navržen a vytvořen nový způsob zobrazení, který lze považovat za grafický. Klient má tedy implementovány dva režimy zobrazení. Oba tyto režimy si dále podrobněji rozebereme. 5.3.1 Textový výpis Textový výpis je proveden následujícím způsobem. Seznam výsledků je vypsán stejným způsobem jako dříve, viz. obrázek 5.2. U každého výsledku jsou vypsány tři nejdůležitějsí informace - název publikace, vydavatel a rok vydání. Další informace se vypíší, když klikneme na malé plus, jak bývá zvykem. Pod tímto seznamem je dále vypsána relevantní část CCS hierarchie s ohledem na nalezené výsledky - obrázek 5.3. Vypisovat celou CCS hierarchii je zbytečné, je velmi rozsáhlá. Vypisuje se tedy relevantní část, tím rozumějme ty třídy, jejichž klasifikaci má alespoň jeden z výsledků a jejich všechny nadtřídy, aby byla cesta ke každé třídě jasná. Dále každá třída, která obsahuje alespoň jeden výsledek je vypsána formou HTML odkazu a vedle jejího názvu máme v závorkách uveden ještě počet nalezených publikací, které odpovídají této klasifikaci, tedy patří do této CCS třídy. Kliknutím na tento odkaz se dostaneme do podrobného výpisu výsledků, vypíší se pouze výsledky požadované CCS třídy a pod nimi se zobrazí opět CCS strom tříd obsažených ve všech výsledcích vyhledávání. Velká většina nalezených výsledků obsahuje informaci o CCS klasifikaci. Pro ty ostatní, které jsou neklasifikovány, slouží odkaz unclassified, který funguje podobně jako odkazy z výše uvedené hierarchie CCS tříd, tj. po kliknutí se nám vypíše seznam neklasifikovaných výsledků. 5.3.2 Grafický výpis Grafický výpis výsledků je o něco pestřejší než textový a uživatel má tak mnohem lepší přehled o výsledcích vyhledávání. Textový výpis se opíral pouze o primární CCS klasifikaci publikace. Ovšem každá publikace může mít mimo jedné primární CCS klasifikace ještě několik dodatečných. Případ, že by měla publikace pouze dodatečné klasifikace nemůže nastat. Dodatečných klasifikací bývá obvykle několik, zhruba jedna až pět. V tomto režimu jsou barevně vykreslovány CCS třídy ve formě oken, název a kód CCS třídy je uveden ve hlavičce okna. Každá ze tříd první úrovně má svoji vlastní barvu, tyto barvy byly zvoleny tak, aby byly co nejvíce odlišné. Dále každá CCS třída druhé a nižší úrovně dědí barvu ze své nadřazené třídy. Výpis probíhá podobně tako v textovém režimu. 25
5.3. VIZUALIZACE Prochází se strom všech CCS tříd a ty které jsou pro nás zajímavé, přesněji řečeno ty, které jsou primární nebo dodatečnou klasifikací některého z výsledků, budou mít ve svém okně zaznamenán daný výsledek či výsledky. Zakreslují se i všechny nadřazené třídy od třídy každého z výsledku, aby byla lépe znázorněna daná vědní oblast. 26
5.3. VIZUALIZACE Obrázek 5.2: Activity diagram vyhledávání 27
5.3. VIZUALIZACE Obrázek 5.3: Textový výpis výsledků vyhledávání 28
5.3. VIZUALIZACE Obrázek 5.4: Výpis CCS hierarchie relevantních tříd 29
Kapitola 6 Zobrazení postupu při vyhledávání Vyhledávání je proces, který může někdy trvat poměrně dlouho, záleží na tom, jaký se zadá limit dokumentů k nalezení. Když je tento limit velký, řekněme třeba 20 či 30 dokumentů, vyhledávání může trvat i několik desítek vteřin. Klient je ovšem navržen tak, že od zadání dotazu až po získání odpovědi od serveru nedělá nic, jen čeká. Takže uživatel nemůže očekávat žádné informace co se týče nějakého postupu při vyhledávání. Vyřešit tento problém bylo mým dalším úkolem. Jelikož se jedná o nějaké zobrazování postupu u klienta a jedná se o stav, kdy uživatel na nic nekliká, jen vidí stránku s nápisem probíhá vyhledávání, čekejte prosím, nabízí se využít technologie AJAX. 6.1 AJAX AJAX (Asynchronous JavaScript and XML) technika vývoje interaktivních webových aplikací. Základní myšlenkou je vytvořit webové stránky tak, že budou reagovat rychleji, protože při komunikaci se serverem se bude přenášet jen minimum potřebných dat. Je totiž mnoho webů, kde uživatel vyplňuje vícestránkový formulář a mimo tohoto formuláře se na stránce vyskytuje mnoho dalších elementů, různé obrázky, animace a podobně. Při každém odeslání jednoho formuláře se posílá klientovi formulář další s tím, že se opět posílá znova kompletní HTML stránka, tedy i ty obrázky a vše ostatní co stránka obsahuje. Stává se, že tento způsob práce bývá často pomalý právě z důvodu opakovaného načítání stejných elementů na různých webových stránkách. Takové vícestránkové vyplňování formuláře může v klasickém případě tedy při použití synchronního HTTP request-response způsobu komunikace vypadat tak, jak je uvedeno na obrázku 6.1 a někdy bývá tento přístup nežádoucí. Naproti tomu přístup technologie AJAX je takový, že AJAX vytvoří další komunikační vrstvu mezi jednou webovou stránkou a serverem, viz. obrázek 6.2. Tato vrstva přebírá požadavky od uživatele a dále jej vyřizuje asynchronně se serverem. Uživatel tedy vidí jednu webovou stránku a pomocí AJAXu se jen mění její obsah, mění se jen konkrétní elementy. Dále lze v tomto případě pomocí Javascriptu provádět různé funkce, které budou volány po nějakých časových intervalech a budou pomocí AJAXu komunikovat se serverem, což je myšlenka, jak implementovat tento požadavek do vyhledávacího systému. A právě tento asynchronní přístup je v případě zobrazování postupu při vyhledávání potřeba. Naše situace je tedy ještě trochu specifičtější tím, že uživatel během vyhledávání 30
6.2. IMPLEMENTACE U SERVERU Obrázek 6.1: Klasická interakce klient-server, zdroj: Phill Ballard - Teach Yourself Ajax in 10 Minutes Obrázek 6.2: AJAX interakce klient-server, zdroj: Phill Ballard - Teach Yourself Ajax in 10 Minutes nezadává žádné požadavky, tudíž je potřeba, aby se informace o aktuálním stavu vyhledávání měnily automaticky po nějakém čase. 6.2 Implementace u serveru Abychom mohli asynchronně získávat nějaké informace o aktuálním stavu vyhledávání musíme provést jistou úpravu serveru, aby byl schopen tyto informace poskytovat. Implementace je taková, že server si pro každý aktuální dotaz pamatuje seznam pluginů, na kterých již vyhledávání skončilo. K tomu slouží třída QueryStatus. Má jeden atribut, tím je statická mapa, která si ke každému klíči - identifikátor dotazu pamatuje seznam prohledaných el. zdrojů. Třída má tři metody, které jsou uvedeny v seznamu níže. Dále je potřeba zajistit komunikaci mezi webovým prohlížečem a serverem. K tomu slouží zmíněný servlet QueryStatusServlet, protože tato komunikace bude probíhat stejným 31
6.3. IMPLEMENTACE U KLIENTA způsobem jako synchronní komunikace webového prohlížeče a webového serveru, tedy nad protokolem HTTP. Tento servlet umí jediné - když dostane HTTP GET požadavek, zjistí si z něj parametr určující identifikaci vyhledávacího dotazu a zavolá výše uvedenou statickou metodu getfinishedplugins(queryid) třídy QueryStatus. Její výstup, kterým je textový řetězec předává přímo do odpovědi na svůj požadavek. public static void setfinishedplugin(string queryid, String pluginid) Tato metoda je volána v okamžiku, kdy server zjistil, že vyhledávání některého z dotazů na některém z pluginů je ukončeno. public static String getfinishedplugins(string queryid) Tato metoda je volána ze servletu QueryStatusServlet, který slouží ke komunikaci s webovým klientem. Webový klient tak získává díky této metodě předhled o tom, které elektornické zdroje jsou již prohledány. public static void queryfinished(string queryid) Tato metoda je volána serverem při ukončení zpracování dotazu. Způsobí odstranění klíče a hodnoty z uvedené mapy. 6.3 Implementace u klienta U klienta je to tak, že při odeslání dotazu se volá ve frameworku Struts akce Search.1.do. Ta zajistí zpracování dotazu z formuláře a předá řízení JSP stránce WaitPlease.jsp. A právě v této stránce je potřeba zobrazování postupu pomocí AJAXu implementovat. Současný stav systému byl takový, že klient zaslal požadavek serveru a po dobu vyhledávání se uživateli zobrazuje pouze hláška, že má čekat a jediný aktivní prvek na této JSP stránce bylo několik velkých teček na řádku. Jejich počet se v průběhu času zvětšoval a až jich bylo moc, zredukoval se na jednu tečku a zase začaly tečky přibývat. Tímto aktivním prvkem chtěl nejspíš autor uživateli naznačit to, že když se dívá na tuto JSP stránku, tak mezitím vyhledávání opravdu probíhá. Ovšem počet teček se zvětšuje o jednu v pravidelném časovém intervalu a pomocí Javascriptu. Tedy tento aktivní prvek běží zcela automaticky a nezávisle na stavu vyhledávání ostatních komponent systému. Zde se tedy tyto blikající tečky nahradily následujícím výpisem stavu vyhledávání, který již zobrazuje aktuální stav vyhledávání, který je pravidelně získáván pomocí AJAXu od aplikace server, která tyto informace o stavu shromažd uje a udržuje. Zobrazení výpisu stavu vyhledávání je znázorněno na obrázku č. 6.3. Na začátku si klient ještě z dotazu zjistí, ve kterých elektronických zdrojích se bude vyhledávat. Pro každý ze zdrojů zapíše jeho název a stav searching... Další funkcionalitu zajišt ují Javascriptové funkce uvedené níže. 32
6.3. IMPLEMENTACE U KLIENTA Obrázek 6.3: Zobrazení výpisu stavu vyhledávání var xmlhttp; function loadstatus() { xmlhttp=getxmlhttpobject() if (xmlhttp==null){ alert ("Browser does not support HTTP Request") ; return; } var url= vezmuserverurl + "/QueryStatus?queryId=" + queryid; xmlhttp.onreadystatechange=statechanged ; xmlhttp.open("get",url,true) xmlhttp.send(null) ; settimeout("loadstatus()", 500) } function GetXmlHttpObject(){ var objxmlhttp=null ; if (window.xmlhttprequest){ objxmlhttp=new XMLHttpRequest() ; } else if (window.activexobject){ objxmlhttp=new ActiveXObject("Microsoft.XMLHTTP") ; } return objxmlhttp } function statechanged() { if(xmlhttp.readystate==4 xmlhttp.readystate=="complete"){ updatestatus( xmlhttp.responsetext ); } } function updatestatus(str){ var array = str.split(, ); var i ; var s; for(i in array ){ s=array[i]; var element; 33
6.3. IMPLEMENTACE U KLIENTA } } if(element = document.getelementbyid( span- +s)){ var html = element.innerhtml ; if(html.charat(html.length - 1 ) ==. ){ element.innerhtml = finished ; element.classname= finished ; } } Proměnná xmlhttp je globální, je tedy zadefinována mimo uvedené funkce, jedná se o klíčovou proměnnou, je to objekt třídy XMLHTTPRequest. Pomocí tohoto objektu můžeme realizovat komunikaci se serverem - viz. obrázek 6.4. Nejprve je ovšem potřeba jej patřičně inicializovat. To bohužel není jednoznačná záležitost, nebot ne všechny prohlížeče považují tento objekt za nativní javascriptový objekt, přesněji řečeno nelze vždy tento objekt inicializovat pomocí klasické konstrukce xmlhttp = new XMLHTTPRequest() ; Tuto konstrukci sice podporuje většina prohlížečů např. Mozilla, Opera, ale nepodporuje ji MS Internet Exporer, což je v současné době jeden z předních prohlížečů. Ten implementuje tento objekt jakožto ActiveX objekt. ActiveX je proprietární technologie Microsoftu, která umožňuje práci s aktivními objekty na webových stránkách. Takže v případě, že je kód volán v prohlížeči MS I.E. je potřeba XMLHTTPRequest inicializovat kontrukcí xmlhttp = new ActiveXObject("Microsoft.XMLHTTP") ; Ale protože obecně nevíme v jakém prohlížeči se bude tento kód interpretovat, musíme zajistit korektní inicializaci pro obecný prohlížeč. To má na starosti funkce GetXmlHttpObject(). Ta zjistí, zda prohlížeč podporuje XMLHTTPRequest jakožto nativní nebo jakožto ActiveX objekt a podle toho jej patřičně inicializuje. Funkce loadstatus() je první podprogram, který se volá a volá se přímo hned po načtění webové stránky. V této funkci se hned na začátku inicializuje výše uvedený XMLHTT- PRequest objekt. Může stát, že se jedná o nějaký zastaralý prohlížeč a inicializace se nepovedla, přesněji funkce GetXmlHttpObject() vrátila null. Pak se pouze zobrazí uživateli zpráva, že tento prohlížeč nepodporuje tuto technologii. To by se ovšem při použití dnešních prohlížečů nemělo stát. Dále sestavíme URL, které se později aplikuje při HTTP GET požadavku. URL se skládá ze tří částí - URL serveru, název servletu, který poskytuje informace o stavu vyhledávání a identifikace dotazu. URL serveru a identifikaci dotazu získáme z globálních proměnných vezmuserverurl a queryid, které byly definovány již dříve. Dále zadefinujeme do XMLHTTPRequestu vlastnost onreadystatechange. Tato vlastnost určuje funkci, která se má zavolat, když se změní stav komunikace se serverem. Poté následuje příprava k vyslání požadavku serveru. Toto se provede pomocí funkce xmlhttp.open("get",url,true) ; 34
6.3. IMPLEMENTACE U KLIENTA Obrázek 6.4: Použití objektu XMLHTTPRequest, zdroj: Phill Ballard - Teach Yourself Ajax in 10 Minutes Tímto se připraví HTTP požadavek, který bude proveden metodou GET na zadané URL. Třetí argument, v našem případě true znamená, že požadavek bude zaslán asynchronně. V opačném případě (false) by to znamenalo, že požadavek bude zaslán synchronně, a stránka by se až do dokončení požadavku zamkla proti dalším operacím, což v našem případě není vůbec potřeba. A konečně provedeme vlastní realizaci HTTP pořadavku pomocí funkce xmlhttp.send(null) ; Argument null je zde z důvodu toho, že posíláme požadavek pomocí metody GET. Tento argument slouží k předání obsahu požadavku v případě použití metody POST. Když dojde ke změně stavu komunikace, XMLHTTPRequest objekt zavolá funkci statechanged() ; V této funkci se ověří, zda-li se stav změnil na stav complete, tedy na stav, kdy je požadavek vyřízen a XMLHTTPRequest již obdržel odpověd. Když ano, volá se dále funkce updatestatus(xmlhttp.responsetext) ; 35