´ SˇKOLA EKONOMICKA ´ V PRAZE VYSOKA Fakulta informatiky a statistiky Katedra informacˇnı´ho a znalostnı´ho inzˇeny´rstvı´
Inteligentnı´ podpora navigace na WWW s vyuzˇitı´m XML Diplomova´ pra´ce
Jirˇ´ı Kosek
Vedoucı´ pra´ce: Ing. Vojteˇch Sva´tek, Dr. kveˇten 2002
Anotace Diplomova´ pra´ce se zaby´va´ proble´my efektivnı´ navigace v prostrˇedı´ WWW. V prvnı´ cˇa´sti pra´ce jsou nastı´neˇny proble´my soucˇasny´ch syste´mu˚ pro vyhleda´va´nı´ a navigaci na Internetu a je popsa´na architektura syste´mu RAINBOW, ktery´ se snazˇ´ı tyto nedostatky prˇekonat. V dalsˇ´ıch kapitola´ch jsou popsa´ny mozˇnosti implementace vybrany´ch komponent syste´mu – komunikacˇnı´ infrastruktury, navigacˇnı´ho rozhranı´ a modulu pro stahova´nı´ stra´nek. V ra´mci cele´ pra´ce je zvazˇova´na mozˇnost pouzˇitı´ XML a prˇ´ıbuzny´ch technologiı´ pro dı´lcˇ´ı cˇa´sti syste´mu. Prakticky´m vy´stupem diplomove´ pra´ce je funkcˇnı´ modul pro stahova´nı´ stra´nek a navigacˇnı´ rozhranı´ pro prohlı´zˇecˇ Mozilla. Navigacˇnı´ rozhranı´ spolupracuje se trˇemi dalsˇ´ımi analyticky´mi moduly.
Podeˇkova´nı´ Ra´d bych podeˇkoval Vojteˇchu Sva´tkovi za vedenı´ a podporu prˇi tvorbeˇ diplomove´ pra´ce.
Prohla´sˇenı´ Prohlasˇuji, zˇe jsem diplomovou pra´ci vypracoval samostatneˇ a pouzˇil pouze literaturu uvedenou v prˇilozˇene´m seznamu. Nema´m na´mitek proti pu˚jcˇenı´ pra´ce se souhlasem katedry ani proti zverˇejneˇnı´ pra´ce nebo jejı´ cˇa´sti.
Kapitola 1 ´ vod U Jeden z proble´mu˚, ktere´ Internet prˇina´sˇ´ı, je informacˇnı´ zahlcenı´. V soucˇasne´ dobeˇ je na Internetu prˇ´ıstupny´ch neˇkolik miliard webovy´ch stra´nek. Nalezenı´ urcˇite´ informace v takove´m mnozˇstvı´ dokumentu˚ je velice obtı´zˇne´. Existujı´ samozrˇejmeˇ sluzˇby jako internetove´ vyhleda´vacˇe nebo katalogy, ktere´ nalezenı´ potrˇebny´ch informacı´ vy´razny´m zpu˚sobem usnadnˇujı´. Osobneˇ vidı´m nejveˇtsˇ´ı proble´m soucˇasny´ch vyhleda´vacı´ch na´stroju˚ v jejich ovla´da´nı´. Jedna´ se o samostatne´ stra´nky a uzˇivatel prˇi hleda´nı´ informace neusta´le prˇecha´zı´ mezi stra´nkami vyhleda´vacˇe a nalezeny´mi stra´nkami vy´sledku. Cely´ proces by prˇitom mohl by´t mnohem interaktivneˇjsˇ´ı – rozhranı´ vyhleda´vacˇe mu˚zˇe by´t zacˇleneˇno prˇ´ımo do prohlı´zˇecˇe, mu˚zˇe uzˇivateli „inteligentneˇ“ nabı´zet nejen vy´sledky hleda´nı´, ale i odkazy na dalsˇ´ı souvisejı´cı´ stra´nky – at’jizˇ trˇeba obsahoveˇ, nebo od stejne´ho autora, patrˇ´ıcı´ stejne´ firmeˇ apod. O vytvorˇenı´ prostrˇedı´ pro snazsˇ´ı vyhleda´va´nı´ a orientaci ve stra´nka´ch usiluje projekt RAINBOW (Reusable Architecture for INtelligent Brokering Of Web information access),1 na ktere´m se podı´lı´ pracovnı´ci z Katedry informacˇnı´ho a znalostnı´ho inzˇeny´rstvı´ a Laboratorˇe inteligentnı´ch syste´mu˚ VSˇE. Moje diplomova´ pra´ce se zaby´va´ neˇktery´mi cˇa´stmi tohoto projektu, prˇedevsˇ´ım celkovou architekturou syste´mu, jeho komunikacˇnı´ infrastrukturou, uzˇivatelsky´m rozhranı´m a modulem pro stahova´nı´ stra´nek. Vy´sledkem pra´ce je prototypova´ implementace RAINBOW, ktera´ mu˚zˇe by´t da´le rozsˇirˇova´na pomocı´ modulu˚ vytvorˇeny´ch ostatnı´mi u´cˇastnı´ky projektu. V na´sledujı´cı´ kapitole jsou podrobneˇji rozebra´ny proble´my vyhleda´va´nı´ na soucˇasne´m webu a nastı´neˇny mozˇnosti jejich rˇesˇenı´ v ra´mci projektu. Trˇetı´ kapitola poda´va´ strucˇny´ prˇehled XML a na neˇj navazujı´cı´ch technologiı´, ktere´ mohou by´t v projektu vyuzˇity. Na´sledneˇ jsou v samostatny´ch kapitola´ch podrobneˇ rozebra´ny ota´zky komunikace mezi komponentami syste´mu RAINBOW (4 – Komunikacˇnı´ infrastruktura), implementace uzˇivatelske´ho navigacˇnı´ho rozhranı´ (5 – Navigacˇnı´ rozhranı´ ) a implementace modulu pro stahova´nı´ stra´nek (6 – Stahova´nı´ a ukla´da´nı´ stra´nek).
1
http://rainbow.vse.cz/
7
Kapitola 2 Prˇı´stupy k navigaci a vyhleda´va´nı´ na webu Internet (a ma´m ted’ na mysli prˇedevsˇ´ım webove´ stra´nky) nabı´zı´ obrovske´ mnozˇstvı´ informacı´. Tyto informace mohou by´t uzˇitecˇne´, mohou by´t k nicˇemu, nebo se dokonce jedna´ o dezinformace. Proble´m je, jak v tomto kvantu1 najı´t ty spra´vne´ stra´nky a jesˇteˇ oveˇrˇit, zda na nich prezentovane´ informace jsou hodnoveˇrne´. Samotne´ nalezenı´ stra´nky, ktera´ obsahuje pozˇadovane´ informace, na za´kladeˇ zadany´ch klı´cˇovy´ch slov dnes nabı´zı´ mnoho sluzˇeb. V soucˇasne´ dobeˇ patrˇ´ı mezi nejzna´meˇjsˇ´ı a nejoblı´beneˇjsˇ´ı vyhleda´vacˇ Google.2 Prˇehled dalsˇ´ıch vyhleda´vacı´ch serveru˚ je mozˇne´ nale´zt naprˇ. na adrese http://dir.yahoo.com/Computers_and_Internet/Internet/World_ Wide_Web/Searching_the_Web/Search_Engines_and_Directories/. Jak vypada´ interakce uzˇivatele s vyhleda´vacı´ sluzˇbou? Dnesˇnı´ vyhleda´vacˇe du˚sledneˇ oddeˇlujı´ fa´zi hleda´nı´ a prohlı´zˇenı´ stra´nek. Uzˇivatel musı´ nejprve co nejprˇesneˇji formulovat dotaz pro vyhleda´vacı´ sluzˇbu. Ta mu vra´tı´ seznam stra´nek, ktere´ by mohly uzˇivatele zajı´mat. Uzˇivatel si ze seznamu podle na´zvu stra´nky a strucˇne´ho vy´tahu vybere potenciona´lneˇ zajı´mavou stra´nku a nacˇte ji do prohlı´zˇecˇe. Pokud stra´nka neodpovı´da´ hledane´ oblasti, musı´ se uzˇivatel vra´tit zpeˇt a zkusit jinou stra´nku z vy´sledku dotazu. Pokud hledana´ informace nenı´ nalezena na veˇtsˇineˇ vra´ceny´ch stra´nek, musı´ uzˇivatel prˇejı´t zpeˇt na stra´nku vyhleda´vacı´ sluzˇby a snazˇit se uprˇesnit dotaz tak, aby byly vy´sledky hleda´nı´ prˇesneˇjsˇ´ı. Tento postup prˇi hleda´nı´ informacı´ nenı´ pro uzˇivatele prˇ´ılisˇ pohodlny´. Neusta´le´ prˇecha´zenı´ mezi stra´nkami a vyhleda´vacı´ sluzˇbou zbytecˇneˇ zdrzˇuje a navı´c zdaleka neprˇedstavuje nejefektivneˇjsˇ´ı zpu˚sob pro rychle´ nalezenı´ pozˇadovany´ch informacı´. Kdyby se na´m podarˇilo inteligentnı´ vyhleda´va´nı´ integrovat s prohlı´zˇenı´m stra´nek, dostali bychom prostrˇedı´, ktere´ by bylo pro uzˇivatele mnohem efektivneˇjsˇ´ı a snazsˇ´ı na ovla´da´nı´. V te´to kapitole pra´ce popı´sˇi, jak by takovy´ inteligentnı´ syste´m navigace po webovy´ch stra´nka´ch mohl vypadat. Dalsˇ´ı cˇa´sti diplomove´ pra´ce pak popisujı´ prototypovou implementaci dı´lcˇ´ıch cˇa´stı´ tohoto syste´mu. Nejprve se vsˇak podı´va´me, jak vypadajı´ a fungujı´ soucˇasne´ beˇzˇneˇ dostupne´ na´stroje pro vyhleda´va´nı´ a navigaci na webu. 1
Odhadnout celkovy´ pocˇet stra´nek dostupny´ch na webu je velmi teˇzˇke´. Naprˇ´ıklad podle studie S. Lawrence a L. Gilese [28] bylo v roce 1999 na webu 800 milio´nu˚ stra´nek. Na jarˇe roku 2002 meˇl vyhleda´vacˇ Google ve sve´m indexu jizˇ 2 miliardy stra´nek a to jisteˇ nezaindexoval cely´ web. 2 http://www.google.com
8
2.1. VYHLEDA´VACI´ SLUZˇBY
2.1
Vyhleda´vacı´ sluzˇby
Vsˇechny vyhleda´vacı´ sluzˇby (naprˇ. Google,3 Altavista,4 nebo cˇesky´ WebFast5 cˇi Webseek6 ) pracujı´ na stejne´m principu. Skla´dajı´ se ze trˇ´ı do velke´ mı´ry samostatny´ch modulu˚ – webove´ho robota (crawlera), indexa´toru a vyhleda´vacı´ho modulu. Webovy´ robot stahuje webove´ stra´nky a ukla´da´ je do databa´ze dokumentu˚. Ze stra´nek se vyberou vsˇechny odkazy na dalsˇ´ı stra´nky a ty se take´ sta´hnou. Na pocˇa´tku se stahova´nı´ zahajuje obvykle pro rucˇneˇ vybrane´ servery, prˇ´ıpadneˇ pro odkazy z neˇjake´ho katalogu. Neˇktere´ vyhleda´vacˇe umozˇnˇujı´ rucˇnı´ zada´nı´ URL adres, ktere´ se majı´ zpracovat. Dost cˇasto se pro zı´ska´nı´ adres jesˇteˇ nezpracovany´ch webovy´ch serveru˚ pouzˇ´ıva´ vytazˇenı´ noveˇ registrovany´ch dome´n ze sluzˇby DNS a test, zda na nich beˇzˇ´ı webovy´ server. Stazˇene´ stra´nky se pote´ zarˇadı´ do indexu pouzˇ´ıvane´ho pro fulltextove´ vyhleda´va´nı´. Pouzˇ´ıvajı´ se prˇitom klasicke´ techniky plnotextove´ho hleda´nı´ – vyrˇazenı´ stop-slov, lemmatizace a zarˇazenı´ slov do invertovane´ho seznamu nebo podobne´ vyhleda´vacı´ struktury. Kdyzˇ pak chce uzˇivatel najı´t stra´nku obsahujı´cı´ urcˇita´ slova nebo fra´ze, pracuje s vyhleda´vacı´m modulem. Ten prohleda´ index, serˇadı´ nalezene´ stra´nky podle relevance a vra´tı´ je uzˇivateli. Vy´sledek je typicky prezentova´n jako samostatna´ webova´ stra´nka se seznamem odkazu˚ na stra´nky vy´sledku (viz obra´zek 2.1). Uzˇivatel se kliknutı´m na na´zev stra´nky ve vy´sledku dostane prˇ´ımo na danou stra´nku. Pokud vsˇak zjistı´, zˇe nalezena´ stra´nka neobsahuje jı´m hledane´ informace, musı´ se rucˇneˇ vra´tit zpeˇt na stra´nku s vy´sledky a zkusit jinou stra´nku, prˇ´ıpadneˇ uprˇesnit dotaz.
Obra´zek 2.1: Klasicke´ vyhleda´vacı´ sluzˇby nutı´ uzˇivatele prˇecha´zet mezi nalezeny´mi stra´nkami a vy´sledkem hleda´nı´ 3
2.2. NAVIGACˇNI´ ASISTENTI Tento zpu˚sob pra´ce s prohleda´vacˇem nenı´ prˇ´ılisˇ pohodlny´. Kdyzˇ se chvı´li pohybujeme po webu, na ktery´ patrˇ´ı stra´nka z vy´sledku, mu˚zˇeme se dostat pomeˇrneˇ daleko (mysˇleno pocˇtem postupneˇ aktivovany´ch odkazu˚) od stra´nky s vy´sledkem hleda´nı´. Tento proble´m do jiste´ mı´ry rˇesˇ´ı noveˇjsˇ´ı prohlı´zˇecˇe nebo prˇ´ıdavne´ moduly, ktere´ zobrazujı´ vy´sledek dotazu v samostatne´m okneˇ, neza´visle na prohlı´zˇene´ stra´nce (obra´zek 2.2).
Obra´zek 2.2: Neˇktere´ prohlı´zˇecˇe zobrazujı´ vy´sledek hleda´nı´ v samostatne´m okneˇ I kdyzˇ jsou podobne´ vyhleda´vacı´ panely z uzˇivatelske´ho hlediska velky´m krokem vprˇed, sta´le nenabı´zejı´ vsˇe, co by uzˇivatel potrˇeboval. Po nalezenı´ stra´nky s pozˇadovany´m te´matem chce uzˇivatel cˇasto nale´zt tematicky stejneˇ zameˇrˇene´ stra´nky. V tomto okamzˇiku by se hodila funkce, ktera´ by pomocı´ shlukove´ analy´zy nebo podobne´ metody nabı´dla uzˇivateli seznam podobny´ch stra´nek.
2.2
Navigacˇnı´ asistenti
Navigacˇnı´ asistenti jizˇ nejsou zdaleka tak rozsˇ´ırˇena´ aplikace jako vyhleda´vacˇe. Pod pojmem navigacˇnı´ asistent myslı´m komponentu webove´ho prohlı´zˇecˇe, ktera´ usnadnˇuje navigaci automaticky´m nabı´zenı´m obsahoveˇ podobny´ch stra´nek apod. Asi nejzna´meˇjsˇ´ı aplikacı´ tohoto druhu je panel What’s Related v prohlı´zˇecˇi Netscape Navigator, resp. Mozilla. Ke kazˇde´ stra´nce, kterou si prohlı´zˇ´ıme, na´m automaticky nabı´zı´ odkazy na souvisejı´cı´ stra´nky, kontaktnı´ informace zı´skane´ z databa´ze dome´novy´ch jmen a jednoduchou statistiku o cele´m webu (viz obra´zek 2.3). Seznam podobny´ch stra´nek nabı´zeny´ch v panelu je prˇitom zı´ska´va´n pomocı´ sluzˇby Alexa.7 Sluzˇby jako Alexa jsou uzˇitecˇne´ zejme´na v druhe´ fa´zi hleda´nı´, kdy uzˇ uzˇivatel nalezl alesponˇ jednu stra´nku s pozˇadovany´mi informacemi. Mu˚zˇe pak velice snadno prˇejı´t na dalsˇ´ı stra´nky veˇnujı´cı´ se dane´mu te´matu. Nicme´neˇ i tato sluzˇba by mohla by´t lepsˇ´ı. Mohla 7
http://www.alexa.com/
10
2.3. PROJEKT RAINBOW A JEHO MOZˇNOSTI PRˇI PODPORˇE NAVIGACE
Obra´zek 2.3: Navigacˇnı´ panel What’s Related v Mozille
by nabı´zet vı´ce druhu˚ informacı´ a metainformacı´ o stra´nce. Podobne´ stra´nky by mohly by´t cˇleneˇny do neˇkolika kategoriı´ – naprˇ. stejne´ obsahoveˇ, od stejne´ho autora, se stejnou strukturou apod. To je smeˇr, ktery´m se ubı´ra´ projekt RAINBOW, jehozˇ vybrane´ cˇa´sti jsou vytva´rˇeny v ra´mci te´to diplomove´ pra´ce.
2.3
Projekt RAINBOW a jeho mozˇnosti prˇi podporˇe navigace
Cı´lu˚ projektu RAINBOW je neˇkolik. Lze je rozdeˇlit do trˇ´ı skupin: • Vytvorˇenı´ navigacˇnı´ho rozhranı´ pro snazsˇ´ı pohyb po souvisejı´cı´ch stra´nka´ch. • Dalsˇ´ı rozsˇ´ırˇenı´ syste´mu VSˇEveˇd [1]. Syste´m VSˇEveˇd pracuje jako nadstavba nad vyhleda´vacı´mi sluzˇbami. Vy´sledky vyhleda´va´nı´ umı´ inteligentneˇ seskupovat a kategorizovat. Uzˇivatel tak dostane uzˇitecˇneˇjsˇ´ı vy´sledek. • Syste´m pro audit stra´nek, ktery´ by hledal chyby na stra´nka´ch a upozornˇoval na neˇ. V soucˇasne´ dobeˇ se pracuje prˇedevsˇ´ım na prvnı´ cˇa´sti projektu, jejı´mzˇ cı´lem je usnadneˇnı´ a zlepsˇenı´ navigace na webovy´ch stra´nka´ch. Z uzˇivatelske´ho pohledu je cı´lem vyvinout rozsˇ´ırˇeny´ prohlı´zˇecˇ webovy´ch stra´nek, ktery´ bude ve specia´lnı´m panelu zobrazovat prˇ´ıdavne´ informace vztahujı´cı´ se k aktua´lneˇ zobrazovane´ stra´nce. Na rozdı´l od panelu What’s Related by meˇl syste´m nabı´zet veˇtsˇ´ı mnozˇstvı´ informacı´ o aktua´lneˇ zobrazene´ stra´nce (viz obra´zek 2.4). Ve fina´lnı´ podobeˇ by navigacˇnı´ asistent RAINBOW mohl ke kazˇde´ stra´nce automaticky nabı´zet na´sledujı´cı´ u´daje: • Sekci metainformacı´ o dokumentu obsahujı´cı´ du˚lezˇite´ informace o aktua´lnı´m dokumentu. Prˇitom by se syste´m nemusel soustrˇed’ovat jen na klasicke´ metainformace jako autor, 11
2.3. PROJEKT RAINBOW A JEHO MOZˇNOSTI PRˇI PODPORˇE NAVIGACE
Obra´zek 2.4: Prototyp navigacˇnı´ho rozhranı´
na´zev, datum vzniku, klı´cˇova´ slova, ale i na me´neˇ obvykle´ – naprˇ. to, zˇe jde o akademickou stra´nku, o obsah vı´cestra´nkove´ho dokumentu apod. • Sekci podobny´ch stra´nek, ktera´ bude pro veˇtsˇinu uzˇivatelu˚ zrˇejmeˇ nejdu˚lezˇiteˇjsˇ´ı, protozˇe umozˇnı´ rychly´ prˇechod na stra´nky podobne´ podle ru˚zny´ch krite´riı´ – syste´m nabı´dne stra´nky shodne´ obsahoveˇ, stra´nky od stejne´ho autora, nebo naprˇ´ıklad stra´nky se stejnou forma´lnı´ strukturou. Uzˇivatel by se tak mohl snadno pohybovat v prostoru pro neˇj zajı´mavy´ch dokumentu˚ bez nutnosti rucˇnı´ pra´ce s neˇjakou vyhleda´vacı´ sluzˇbou. • Sekci asociovany´ch stra´nek odkazujı´cı´ na stra´nky, ktere´ s tou aktua´lnı´ jisty´m zpu˚sobem souvisejı´ (a nejde prˇitom o symetrickou podobnost). Patrˇ´ı sem naprˇ´ıklad odkazy na prˇedchozı´ a na´sledujı´cı´ stra´nku v ra´mci dokumentu slozˇene´ho z vı´ce fyzicky´ch stra´nek, na hlavnı´ stra´nku, na stra´nku s hleda´nı´m apod. To umozˇnˇuje snadny´ pohyb i po sˇpatneˇ navrzˇeny´ch stra´nka´ch, ktere´ neobsahujı´ vlastnı´ navigacˇnı´ prvky. • Sekci dome´noveˇ za´visly´ch informacı´ obsahujı´cı´ v kondenzovane´ podobeˇ jak metainformace, tak asociace, ovsˇem takove´, ktere´ jsou specificke´ pro jistou proble´movou oblast a jako takove´ popsane´ specializovanou ontologiı´. V ra´mci webove´ho mı´sta univerzity mu˚zˇe jı´t naprˇ´ıklad o identifikaci stra´nky kurzu, vyucˇujı´cı´ho a katedry a jejich vza´jemne´ odkazova´nı´. V ra´mci firemnı´ho webu firmy pak naprˇ. o hlavnı´ stra´nku, stra´nku s referencemi na klienty a stra´nky produktu˚. Ma´-li by´t navigacˇnı´ rozhranı´ opravdu ergonomicke´, meˇlo by nabı´zet mozˇnost personalizace – individua´lnı´ho nastavenı´ podle potrˇeb uzˇivatele. Uzˇivatel by meˇl mı´t mozˇnost vybrat si, jake´ typy informacı´ mu ma´ syste´m nabı´zet. Vy´sˇe popsane´ u´lohy nelze veˇtsˇinou realizovat v rea´lne´m cˇase tak, aby meˇl cely´ syste´m dostatecˇneˇ rychlou odezvu. RAINBOW proto pracuje podobny´m zpu˚sobem jako klasicke´ internetove´ vyhleda´vacˇe. Prˇedem se vzˇdy zpracuje urcˇita´ cˇa´st webu – naprˇ´ıklad stra´nky jedne´ 12
2.3. PROJEKT RAINBOW A JEHO MOZˇNOSTI PRˇI PODPORˇE NAVIGACE univerzity, firmy, sta´tu, nebo trˇeba pru˚myslove´ho odveˇtvı´. Stra´nky se sta´hnou, provede se jejich analy´za a zı´skane´ informace se ulozˇ´ı do faktua´lnı´ znalostnı´ ba´ze. Z te´to ba´ze znalostı´ se pak zı´ska´vajı´ potrˇebne´ u´daje pro navigacˇnı´ rozhranı´. Prˇi analyzova´nı´ stra´nek neˇktery´mi moduly mohou by´t extrahova´ny i informace du˚lezˇite´ pro audit stra´nek – naprˇ´ıklad syntakticke´ chyby, chybeˇjı´cı´ metadata – a odesla´ny autorovi stra´nky (pokud se ze stra´nky podarˇ´ı zı´skat jeho e-mailovou adresu). Vlastnı´ analy´zou obsahu a struktury stra´nek a prˇ´ıslusˇny´mi analyticky´mi moduly se v te´to pra´ci nezaby´va´m. Jde o velmi na´rocˇnou za´lezˇitost, ktera´ vyzˇaduje zapojenı´ technik umeˇle´ inteligence, znalostnı´ho inzˇeny´rstvı´ apod. V ra´mci projektu RAINBOW se pocˇ´ıta´ s vy´vojem na´sledujı´cı´ch modulu˚: • extrakce informacı´ z textu; • analy´za metadat explicitneˇ prˇ´ıtomny´ch ve webovy´ch dokumentech; • analy´za URL adres; • analy´za struktury znacˇek; • frekvencˇnı´ analy´za termı´nu˚; • analy´za topologie odkazu˚; • analy´za obrazovy´ch informacı´.
Internet
konzultace s externími vyhledávacími službami
ížeč ázková webová stránka
dotazovací (agregační) modul
ého autora
navigační rozhraní é stránky
xxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxx xxxx xxxx xxxxxx xxxxxxxx xxxxxxxxx xxxxxxx xxxx xxxxxxxxxx x x xxxxxxxx xxxxxxxx xxx xxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxx xxxx xxxx xxxxxx xxxxxxxx xxxxxxxxx xxxxxxx xxxx xxxxxxxxxx x x xxxxxxxx xxxxxxxx xxx
uživatel
znalosti a metadata o stránkách
HTML a XHTML stránky
xxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxx xxxx xxxx xxxxxx xxxxxxxx xxxxxxxxx xxxxxxx xxxx xxxxxxxxxx x x xxxxxxxx xxxxxxxx xxx
prezentační brána pro navigační rozhraní
ížeč
prezentační brána pro vizualizační rozhraní
vizualizační rozhraní
modul pro stahování stránek
uživatel
Analytické moduly
I
A
znalosti a metadata o stránkách
stránky převedené do XML/XHTML
R
databáze stažených stránek
B
O W
stránky/ části stránek převedené do XML/XHTML
N
faktuální báze znalostí
RAINBOW – Architektura
Obra´zek 2.5: Architektura RAINBOW Prˇehledove´ sche´ma cele´ho syste´mu je zachyceno na obra´zku 2.5. Modul pro stahova´nı´ stra´nek se stara´ o stazˇenı´ stra´nek z vybrane´ cˇa´sti Internetu. Jelikozˇ mnoho soucˇasny´ch webovy´ch stra´nek obsahuje syntakticke´ chyby, ktere´ by ztı´zˇily pra´ci dalsˇ´ım analyticky´m modulu˚m, jsou tyto chyby odstraneˇny, stra´nky prˇevedeny do XML a na´sledneˇ ulozˇeny do databa´ze stazˇeny´ch stra´nek. 13
2.3. PROJEKT RAINBOW A JEHO MOZˇNOSTI PRˇI PODPORˇE NAVIGACE Z te´to databa´ze se stra´nky prˇedajı´ analyticky´m modulu˚m, ktere´ se v nich pokusı´ nale´zt metadata, ru˚zne´ souvislosti a dalsˇ´ı zajı´mave´ u´daje. Tyto u´daje se pak ulozˇ´ı do faktua´lnı´ ba´ze znalostı´. Bude-li chtı´t uzˇivatel pracovat se syste´mem, musı´ mı´t nainstalova´n specia´lnı´ prohlı´zˇecˇ, ktery´ pro pra´veˇ prohlı´zˇenou stra´nku kontaktuje dotazovacı´ modul. Ten zjistı´ od ostatnı´ch modulu˚ a z faktua´lnı´ ba´ze informace o aktua´lnı´ stra´nce a prˇeda´ je zpeˇt navigacˇnı´mu rozhranı´. Podle povahy u´daju˚ mu˚zˇe dotazovacı´ modul neˇktere´ informace zı´skat „on-line“ od urcˇity´ch analyticky´ch modulu˚, prˇ´ıpadneˇ od externı´ch sluzˇeb dostupny´ch mimo RAINBOW. Tyto vy´sledky se zkombinujı´ se slozˇiteˇji zı´skany´mi informacemi, ktere´ jsou ulozˇeny „off-line“ v jizˇ zmı´neˇne´ faktua´lnı´ ba´zi znalostı´. Dotazovacı´ modul prˇitom nekomunikuje prˇ´ımo s uzˇivatelem, resp. rozhranı´m, ktere´ uzˇivatel pouzˇ´ıva´. Mezi uzˇivatele a dotazovacı´ modul je vlozˇena jesˇteˇ jedna vrstva, ktera´ umozˇnˇuje prˇevedenı´ zı´skany´ch informacı´ o stra´nce do ru˚zny´ch podob. Kromeˇ drˇ´ıve popsane´ho navigacˇnı´ho rozhranı´ tak mu˚zˇe pozdeˇji vzniknout i dalsˇ´ı rozhranı´, ktere´ bude vy´sledky prezentovat odlisˇnou formou – naprˇ. vizua´lneˇ. Inspirovat se v tomto prˇ´ıpadeˇ mu˚zˇeme naprˇ´ıklad syste´mem Visual.net firmy Antarcti.ca, ktery´ umozˇnˇuje prostorovou vizualizaci informacˇnı´ho prostoru (a tedy i Internetu).
Obra´zek 2.6: Antarcti.ca – katalog stra´nek prezentovany´ jako shluky v 2D prostoru Cı´lem me´ diplomove´ pra´ce je vytvorˇenı´ modulu pro stahova´nı´ stra´nek, navigacˇnı´ho rozhranı´, navrzˇenı´ a otestova´nı´ vhodne´ komunikacˇnı´ infrastruktury pro moduly.
14
Kapitola 3 Prˇehled XML technologiı´ a mozˇnostı´ jejich vyuzˇitı´ Z prˇedchozı´ho popisu je patrne´, zˇe RAINBOW je jizˇ pomeˇrneˇ komplikovany´ syste´m, prˇi jehozˇ implementaci se musı´me vyporˇa´dat s rˇadou prakticky´ch u´kolu˚. Musı´me uchova´vat zdrojove´ webove´ stra´nky a z nich zı´skane´ znalosti, zajistit komunikaci ru˚zny´ch programovy´ch komponent a prezentaci informacı´ uzˇivateli. Abychom nemuseli pouzˇ´ıvat prˇ´ılisˇ rozdı´lne´ na´stroje a forma´ty, rozhodli jsme se v maxima´lnı´ mozˇne´ mı´rˇe vyuzˇ´ıt jazyk XML a na´vazne´ technologie. Za´rovenˇ jsem chteˇl oveˇrˇit, na co vsˇechno lze XML pouzˇ´ıt, a jake´ jsou jeho limity zejme´na prˇi rychlosti zpracova´nı´. XML (eXtensible Markup Language) [6] je jednoduchy´ znacˇkovacı´ jazyk, ktery´ umozˇnˇuje uchova´nı´ dat te´meˇrˇ libovolne´ho typu. V odvozeny´ch forma´tech zalozˇeny´ch na XML mu˚zˇeme pouzˇ´ıvat vlastnı´ znacˇky a s jejich pomocı´ zachytit vy´znam a vztah mezi jednotlivy´mi informacemi (viz naprˇ. [24]). Syntaxe vsˇak vzˇdy vycha´zı´ z jazyka XML, a proto mu˚zˇeme pouzˇ´ıvat jizˇ existujı´cı´ standardnı´ knihovny pro zpracova´nı´ XML dokumentu˚. To na´m mu˚zˇe usˇetrˇit spoustu pra´ce. Kromeˇ toho je nad XML vystaveno mnoho dalsˇ´ıch uzˇitecˇny´ch jazyku˚, ktere´ lze v aplikaci vyuzˇ´ıt. Hlavnı´ vy´hoda spocˇ´ıva´ v tom, zˇe se pouzˇ´ıvajı´ zna´me´ technologie a zˇe i pro tyto jazyky jsou k dispozici jizˇ existujı´cı´ knihovny. V na´sledujı´cı´m prˇehledu se podı´va´me na neˇktere´ XML jazyky a technologie, ktere´ u´zce navazujı´ na XML, a posoudı´me mozˇnost jejich vyuzˇitı´ v RAINBOW.
3.1 XML Popisovat na tomto mı´steˇ syntaxi XML by bylo asi zbytecˇne´. Prˇipomenˇme si tedy jen, zˇe XML dokument se skla´da´ z pojmenovany´ch elementu˚. Kazˇdy´ element prˇitom mu˚zˇe obsahovat text a dalsˇ´ı vnorˇene´ elementy. XML dokument si tak lze prˇedstavit jako hierarchickou stromovou strukturu. Tato datova´ struktura je velmi oblı´bena´ a lze do nı´ ulozˇit v podstateˇ libovolne´ informace. Kazˇdy´ element mu˚zˇe mı´t u sebe prˇ´ıtomny´ch jesˇteˇ neˇkolik atributu˚, cozˇ jsou usporˇa´dane´ dvojice obsahujı´cı´ jme´no atributu a jeho hodnotu.
3.1.1 Infoset Z teoreticke´ho hlediska je pro XML velmi du˚lezˇity´ pojem tzv. infosetu – informacˇnı´ mnozˇiny (XML Information Set) [10]. Z historicky´ch du˚vodu˚ popisuje standard jazyka XML [6] prˇ´ımo 15
3.1. XML syntaxi jazyka, nezaby´va´ se datovy´m modelem, ktery´ XML dokumenty pouzˇ´ıvajı´. Tento prˇ´ıstup sice umozˇnil celkem rychle´ prˇijetı´ XML a jeho sˇirokou podporu v aplikacı´ch, na druhou stranu poneˇkud kompikuje vy´voj dalsˇ´ıch standardu˚ navazujı´cı´ch na XML, zejme´na programa´torsky´ch rozhranı´ (API) pro cˇtenı´ XML dokumentu˚ a dotazovacı´ch jazyku˚. Infoset definuje abstraktnı´ datovy´ model pro XML dokumenty. Model prˇitom vycha´zı´ ze stromove´ struktury, kde ma´ kazˇdy´ uzel definova´ny vlastnosti popisujı´cı´ jeho typ a dalsˇ´ı nava´zane´ uzly (tj. vnorˇene´ elementy, atributy apod.). Na rozdı´l od samotne´ho standardu XML jizˇ infoset neoperuje s jednotlivy´mi znaky v souboru, ale s elementy, atributy, textovy´m obsahem elementu˚ apod. Je tedy o jednu u´rovenˇ abstrakce vy´sˇe nezˇ samotny´ standard XML, ktery´ prˇesneˇ popisuje syntaxi XML pomocı´ EBNF.1
3.1.2 Jmenne´ prostory Pokud potrˇebujeme do XML ukla´dat neˇjaky´ druh informacı´, vytvorˇ´ıme si pro tento u´cˇel obvykle vlastnı´ znacˇkovacı´ jazyk, vlastnı´ sadu znacˇek. Rozhodneme se tedy, jak se budou jednotlive´ elementy jmenovat a jak mohou by´t navza´jem kombinova´ny. Tuto definici mu˚zˇeme zapsat i forma´lneˇ pomocı´ neˇjake´ho jazyka pro popis sche´matu dokumentu jako jsou DTD, XML sche´mata (XML Schema) nebo Relax NG. Proble´m ovsˇem nastane, chceme-li v jednom dokumentu pouzˇ´ıt vı´ce sad znacˇek – mu˚zˇe dojı´t naprˇ´ıklad ke konfliktu na´zvu˚ elementu˚ apod. Tento proble´m rˇesˇ´ı jmenne´ prostory [7]. Jedna´ se o samostatny´ standard, ktery´ velmi u´zce doplnˇuje samostny´ standard XML. Dokonce se pla´nuje, zˇe v dalsˇ´ım vyda´nı´ standardu XML bude vsˇe shrnuto v jednom dokumentu. Jmenne´ prostory fungujı´ na jednoduche´m principu. Kazˇdy´ element a atribut mu˚zˇe by´t prˇirˇazen ke jmenne´mu prostoru, ktery´ je identifikova´n URI adresou. Pro zkra´cenı´ za´pisu se pak v XML dokumentu deklarujı´ pro pouzˇite´ jmenne´ prostory kra´tke´ prefixy, ktere´ se pouzˇ´ıvajı´ pro prˇirˇazenı´ elementu nebo atributu do urcˇite´ho jmenne´ho prostoru. Z na´sledujı´cı´ uka´zky je patrne´, jak se za´pis zkra´tı´, nebot’ pomeˇrneˇ dlouhe´ URI je v dokumentu uvedeno jen jednou. Obsah elementu Y ve jmenne ´m prostoru urn:x-pokus:aObsah elementu Y ve jmenne ´m prostoru urn:x-pokus:b
3.1.3 Jazyky pro popis sche´matu dokumentu˚ XML na´m sice umozˇnˇuje libovolne´ pojmenova´nı´ elementu˚, ale pro veˇtsˇinu prakticky´ch aplikacı´ nenı´ prˇ´ılisˇna´ volnost zˇa´doucı´. Pro kazˇdou trˇ´ıdu XML dokumentu˚ proto mu˚zˇeme pomocı´ specia´lnı´ho jazyka prˇesneˇ forma´lneˇ definovat, jake´ elementy lze v dokumentu pouzˇ´ıt, jake´ mohou mı´t atributy a obsah. Teˇmto jazyku˚m se rˇ´ıka´ jazyky pro definova´nı´ sche´matu dokumentu. Historicky nejstarsˇ´ım a nejzna´meˇjsˇ´ı je bezesporu definice typu dokumentu – DTD (Document Type Definition), ktera´ vznikla jizˇ pro jazyk SGML a byla prˇevzata i do XML. DTD pro soucˇasne´ aplikace v mnoha ohledech nedostacˇujı´. Jejich asi nejveˇtsˇ´ım proble´mem je sˇpatna´ podpora jmenny´ch prostoru˚ a datovy´ch typu˚. Postupem cˇasu proto vznikly i dalsˇ´ı jazyky pro popis sche´matu, ktere´ nedostatky DTD odstranˇujı´. Nejpouzˇ´ıvaneˇjsˇ´ı jsou 1
Extended Backus-Naur Form (EBNF) je cˇasto pouzˇ´ıvany´ zpu˚sob za´pisu bezkontextove´ gramatiky.
16
3.1. XML dnes XML sche´mata [14], ktera´ jsou standardem W3C. Jedna´ se o jazyk postaveny´ na definici datovy´ch typu˚, ktery´ nabı´zı´ mnoho funkcı´ – vcˇetneˇ definovanı´ vlastnı´ch datovy´ch typu˚, referencˇnı´ integrity a integritnı´ch omezenı´. Proble´m XML sche´mat je v tom, zˇe se jedna´ o pomeˇrneˇ slozˇity´ standard, kde jde jednu veˇc deˇlat mnoha ru˚zny´mi zpu˚soby. Nicme´neˇ velke´ IT firmy vcˇetneˇ Microsoftu XML sche´mata podporujı´ (Microsoft na nich ostatneˇ zalozˇil kompletnı´ pra´ci s relacˇnı´mi daty v .NET Frameworku). Alternativou k XML sche´matu˚m je jazyk Relax NG [8], ktery´ je podobneˇ jako DTD postaven na definici gramatiky a pro veˇtsˇinu pouzˇitı´ je tedy mnohem jednodusˇsˇ´ı nezˇ XML sche´mata. Lze v neˇm navı´c urcˇit i datove´ typy. V soucˇasne´ dobeˇ probı´ha´ standardizacˇnı´ proces na pu˚deˇ organizace ISO [18]. Pokud ma´me k dokumentu sche´ma, mu˚zˇeme beˇhem cˇtenı´ kontrolovat, zda dokument sche´matu vyhovuje. Prova´dı´me pak tzv. validaci. Vy´hodou tohoto prˇ´ıstupu je prˇedevsˇ´ım zjednodusˇenı´ aplikacı´ – ty jizˇ nemusı´ kontrolovat tolik chybovy´ch stavu˚ ve vstupnı´ch datech, mnoho chyb odhalı´ jizˇ validace. Validace prˇina´sˇ´ı jesˇteˇ jeden du˚lezˇity´ koncept, ktery´ vyuzˇ´ıvajı´ prˇedevsˇ´ım dotazovacı´ jazyky nad XML. Ke kazˇde´mu XML dokumentu existuje jeho abstraktnı´ reprezentace v podobeˇ infosetu. Pokud ma´me k dokumentu sche´ma, mu˚zˇeme podle neˇj jednotlivy´m uzlu˚m infosetu prˇirˇadit datove´ typy – zı´ska´me tak tzv. PSVI (Post-Schema Validation Infoset) – otypovany´ infoset. V dokumentu jizˇ nejsou vsˇechna data cha´pa´na jako textove´ rˇeteˇzce, ale jako konkre´tnı´ datove´ typy – cˇ´ısla, datumy, rˇeteˇzce, meˇnove´ u´daje apod. Nad PSVI jizˇ mu˚zˇeme budovat dotazovacı´ jazyk, ktery´ doka´zˇe jednodusˇe prova´deˇt operace jako rˇazenı´ cˇi vy´pocˇty agregacˇnı´ch funkcı´, jezˇ jsou za´visle´ na datove´m typu zpracova´vany´ch u´daju˚.
3.1.4 Parsery a programa´torska´ rozhranı´ Pokud chceme s XML dokumenty pracovat v neˇjake´ aplikaci, nemusı´me si sami psa´t analyza´tor XML, ale mu˚zˇe vyuzˇ´ıt neˇktery´ z mnoha jizˇ existujı´cı´ch parseru˚. Parser2 je program nebo programa´torska´ knihovna, jezˇ cˇte XML dokument ze souboru (nebo z jine´ho zdroje – naprˇ. z webove´ho serveru prˇes HTTP protokol) a stara´ se o nı´zkou´rovnˇovou syntaktickou analy´zu XML dokumentu – za mensˇ´ıtkem (<) ocˇeka´va´ na´zev elementu, extrahuje hodnotu atributu uzavrˇene´ho v uvozovka´ch nebo apostrofech apod. Prˇes programa´torske´ rozhranı´ (API) pak parser nabı´zı´ abstraktnı´ model XML dokumentu – infoset. Samotny´ XML dokument resp. jeho infoset na´m mu˚zˇe by´t nabı´zen neˇkolika zpu˚soby a historicky se proto vyvinulo neˇkolik ru˚zny´ch API, ktere´ se hodı´ pro ru˚zne´ aplikace. Prvnı´ parsery nabı´zely rozhranı´ rˇ´ızene´ uda´lostmi. Parser postupneˇ cˇetl XML dokument a volal nasˇe funkce pro obsluhu du˚lezˇity´ch uda´lostı´, jako zacˇa´tek a konec elementu, textovy´ obsah elementu apod. Funkci byly navı´c prˇeda´ny dalsˇ´ı du˚lezˇite´ parametry – naprˇ´ıklad na´zev elementu, seznam atributu˚ apod. Uda´lostmi rˇ´ızene´ zpracova´nı´ XML dokumentu ma´ dveˇ velke´ vy´hody – je rychle´ a ma´ male´ pameˇt’ove´ na´roky. V aplikacı´ch, kde je hlavnı´ du˚raz kladen na rychlost, se proto tento prˇ´ıstup pouzˇ´ıva´ nejcˇasteˇji. Nevy´hodou je naopak nutnost zpracovat XML dokument beˇhem jednoho sekvencˇnı´ho pru˚chodu. Zejme´na zacˇ´ınajı´cı´ programa´torˇi majı´ s touto technikou proble´my, nebot’du˚lezˇite´ informace si programa´tor musı´ pamatovat ve vlastnı´ch stavovy´ch promeˇnny´ch apod. 2
Spra´vneˇ bych meˇl pouzˇ´ıvat pojem „parser XML“, protozˇe pojem parser obecneˇ oznacˇuje libovolny´ syntakticky´ analyza´tor, ne jen ten specializovany´ na XML. Pro snazsˇ´ı cˇitelnost textu prˇ´ıvlastek XML neuva´dı´m.
17
3.1. XML Asi nejzna´meˇjsˇ´ı rozhranı´ pouzˇ´ıvajı´cı´ uda´lostmi rˇ´ızeny´ prˇ´ıstup je SAX (Simple API for XML) [31]. Toto rozhranı´ vzniklo velmi rychle jako vy´sledek spolecˇne´ho u´silı´ neˇkolika vy´voja´rˇu˚ e-mailove´ konference xml-dev. Pu˚vodneˇ byl SAX navrzˇen pro Javu, ale existujı´ jeho implementace pro mnoho dalsˇ´ıch jazyku˚. V soucˇasne´ dobeˇ se jizˇ pouzˇ´ıva´ noveˇjsˇ´ı verze rozhranı´ SAX2, ktera´ podporuje jmenne´ prostory a neˇktere´ dalsˇ´ı uzˇitecˇne´ vlastnosti. Pro pra´ci programa´tora je mnohem pohodlneˇjsˇ´ı, kdyzˇ mu˚zˇe kdykoliv prˇistupovat k libovolne´ cˇa´sti XML dokumentu. Aby to bylo mozˇne´, je nutne´ nacˇ´ıst cely´ dokument do vhodne´ pameˇt’ove´ struktury. XML dokumenty a jejich strukturu lze velmi prˇirozeneˇ modelovat pomocı´ stromu. Nejzna´meˇjsˇ´ı rozhranı´, ktere´ pracuje se stromovou reprezentacı´ dokumentu, je DOM (Document Object Model) [19]. Toto rozhranı´ vytvorˇilo W3C konsorcium a je zcela neza´visle´ na pouzˇite´m jazyku. XML dokument je zprˇ´ıstupneˇn pomocı´ objektu˚, ktere´ zastupujı´ jednotlive´ du˚lezˇite´ prvky – elementy, atributy, textovy´ obsah, komenta´rˇe apod. Kazˇdy´ objekt odpovı´da´ jednomu uzlu ve stromu XML dokumentu a nabı´zı´ metody pro zjisˇteˇnı´ sve´ho typu a hodnoty, svy´ch deˇtı´ a rodicˇu˚. Strom dokumentu mu˚zˇeme procha´zet libovolneˇ a opakovaneˇ. Dı´ky tomu je zpracova´nı´ XML dokumentu velmi jednoduche´. Zaplatı´me za to nizˇsˇ´ı rychlostı´ a velkou pameˇt’ovou na´rocˇnostı´. Prˇi nacˇ´ıta´nı´ XML dokumentu do pameˇti musı´me pocˇ´ıtat s tı´m, zˇe dokument v pameˇti zabere v za´vislosti na pouzˇite´ implementaci dvakra´t azˇ desetkra´t vı´ce prostoru nezˇ v souboru. U souboru˚ s hodneˇ elementy a atributy je navı´c nacˇtenı´ dokumentu dost pomale´, protozˇe se pro kazˇdy´ element a atribut vytva´rˇ´ı v pameˇti objekt. Na rozdı´l od rozhranı´ SAX slouzˇ´ıcı´ho pouze pro cˇtenı´ XML dokumentu˚, umozˇnˇuje DOM s reprezentacı´ XML dokumentu v pameˇti manipulovat, dokonce mu˚zˇeme vytvorˇit novy´ XML dokument prˇ´ımo v pameˇti. Je poneˇkud zara´zˇejı´cı´, zˇe soucˇasna´ verze DOMu nenabı´zı´ standardnı´ metody pro nacˇtenı´ a ulozˇenı´ XML dokumentu, takzˇe kazˇdy´ parser je musı´ rˇesˇit po sve´m. Tento nedostatek odstranˇuje azˇ pra´veˇ prˇipravovana´ verze DOM3. Rozhranı´ DOM ma´ za sebou pomeˇrneˇ dlouhou historii sahajı´cı´ do poloviny 90. let minule´ho stoletı´. O DOM se poprve´ hovorˇilo v souvislosti s JavaScriptem a jazykem HTML. JavaScript mohl prˇes rozhranı´ DOM pracovat s du˚lezˇity´mi informacemi na stra´nce zobrazene´ ve webove´m prohlı´zˇecˇi – prˇ´ıstupne´ byly naprˇ. obra´zky, formula´rˇe a ra´my. Dalsˇ´ı rozvoj DOM vyu´stil azˇ v dynamicke´ HTML, ktere´ umozˇnˇuje vytva´rˇet skutecˇneˇ interaktivnı´ stra´nky. Velky´m proble´mem vsˇak byla (a bohuzˇel sta´je jesˇteˇ trochu je) nekompatibilita DOM rozhranı´ v jednotlivy´ch prohlı´zˇecˇ´ıch. W3C konsorcium proto toto rozhranı´ standardizovalo a vznikl tak DOM1, ktery´ ve skutecˇnosti obsahuje dveˇ velmi odlisˇna´ rozhranı´. Jedno pro pra´ci s HTML dokumenty a druhe´ pro zpracova´nı´ XML – tzv. XML Core. Tato cˇa´st rozhranı´ je pak podporova´na DOM XML parsery. Dalsˇ´ı verze rozhranı´ DOM2 prˇinesla zejme´na podporu jmenny´ch prostoru˚. Navı´c byla prˇida´na dalsˇ´ı rozhranı´, ktera´ umozˇnila mj. snazsˇ´ı pru˚chod stromem dokumentu. Do te´ doby bylo nutne´ pro pru˚chod stromem vyuzˇ´ıvat nestandardnı´ trˇ´ıdy (tzv. treewalkery) nebo si psa´t vlastnı´ ko´d, ktery´ obvykle rekurzivneˇ procha´zel strom. DOM a SAX poskytujı´ velmi komplexnı´ podporu pro cˇtenı´ XML dokumentu˚. Postupem cˇasu se vsˇak uka´zalo, zˇe pro typicke´ u´lohy je jejich pouzˇitı´ zbytecˇneˇ komplikovane´. Beˇhem necely´ch poslednı´ch dvou let se proto sta´le cˇasteˇji objevujı´ nova´ rozhranı´ nebo rozsˇ´ırˇenı´ teˇch sta´vajı´cı´ch, ktera´ majı´ jeden spolecˇny´ cı´l – usnadnit programa´toru˚m pra´ci s XML dokumenty. Autorˇi teˇchto novy´ch prˇ´ıstupu˚ majı´ na mysli zejme´na zkra´cenı´ doby nutne´ na naucˇenı´ pra´ce s novy´m rozhranı´m a na zkra´cenı´ de´lky ko´du nutne´ho pro provedenı´ urcˇite´ operace (cozˇ je ekvivalentnı´ se zkra´cenı´m doby vy´voje aplikace). Po pocˇa´tecˇnı´m nadsˇenı´ z rozhranı´ DOM veˇtsˇina vy´voja´rˇu˚ zjistı´, zˇe je pomeˇrneˇ pracne´ napsat ko´d, ktery´ zpracuje urcˇite´ specificke´ cˇa´sti dokumentu. Prˇisˇlo se proto s mozˇnostı´ polozˇit nad DOM stromem jednoduchy´ dotaz, ktery´ vybere jen urcˇite´ uzly stromu – tedy 18
3.2. ODKAZY MEZI DOKUMENTY urcˇite´ elementy, atributy cˇi textove´ uzly. Jasny´m kandida´tem na takovy´ dotazovacı´ jazyk je XPath (XML Path Language), ktery´ se pouzˇ´ıva´ v mnoha dalsˇ´ıch XML standardech (XSLT, XML sche´mata, XPointer aj.). XPath umozˇnˇuje zada´vat jednoduche´ dotazy, podobne´ cesteˇ v adresa´rˇove´ strukturˇe disku, ktere´ vybı´rajı´ cˇa´sti ze struktury XML dokumentu. Zjednodusˇenı´ se docˇkaly i parsery, ktere´ pracujı´ nad XML dokumentem sekvencˇneˇ. O parserech podporujı´cı´ch rozhranı´ SAX se neˇkdy rˇ´ıka´, zˇe jsou to tzv. push parsery – tlacˇ´ı do aplikace proud uda´lostı´ odpovı´dajı´cı´ jednotlivy´m prvku˚m XML dokumentu. Tento na uda´lostech postaveny´ prˇ´ıstup nenı´ vsˇem programa´toru˚m vlastnı´, a tak vznikly pull parsery. Majı´ vsˇechny prˇednosti uda´lostmi rˇ´ızeny´ch parseru˚ – rychlost a pameˇt’ovou nena´rocˇnost – a navı´c se s nimi velmi jednodusˇe pracuje. Programa´tor si podle potrˇeby rˇ´ıka´ o dalsˇ´ı a dalsˇ´ı cˇa´sti dokumentu a parser mu je postupneˇ prˇeda´va´, dokud nedorazı´ na konec dokumentu.
3.1.5 Vyuzˇitı´ XML prˇi ukla´da´nı´ a zpracova´nı´ dokumentu˚ Pro potrˇeby syste´mu RAINBOW musı´me nacˇ´ıtat webove´ stra´nky a ty pak analyzovat ru˚zny´mi metodami. Pro u´speˇsˇnou analy´zu dokumentu potrˇebujeme zna´t i strukturu webovy´ch stra´nek. To by teoreticky nemeˇl by´t proble´m, protozˇe HTML stra´nky by meˇly odpovı´dat standardu SGML [23] a pro jejich snadne´ cˇtenı´ by tedy meˇlo jı´t vyuzˇ´ıt SGML parser, ktery´ na´m zprˇ´ıstupnı´ i informace o strukturˇe dokumentu. Veˇtsˇina SGML parseru˚ je ovsˇem pro nasˇe u´cˇely prˇ´ılisˇ teˇzˇkopa´dna´ a navı´c veˇtsˇina soucˇasny´ch webovy´ch stra´nek standardu HTML (a tı´m pa´dem ani SGML) nevyhovuje, protozˇe obsahuje spoustu syntakticky´ch chyb. Pomeˇrneˇ snadno vsˇak mu˚zˇeme pomocı´ programu HTML-Tidy3 odstranit ze sta´vajı´cı´ch HTML stra´nek syntakticke´ chyby a prˇeve´st je do forma´tu XML. Tı´m zı´ska´me dokumenty, ktere´ pu˚jde snadno cˇ´ıst pomocı´ velke´ho mnozˇstvı´ dostupny´ch XML parseru˚ a navı´c budeme mı´t zprˇ´ıstupneˇnou strukturu dokumentu˚. Tento prˇ´ıstup – prˇevod HTML stra´nek do XML – se na´m vyplatı´ i z dlouhodobeˇjsˇ´ıho hlediska, protozˇe se na webu zacˇ´ınajı´ postupneˇ objevovat stra´nky, ktere´ jsou zapsa´ny prˇ´ımo v XML nebo v XHTML, cozˇ je na´stupce jazyka HTML zalozˇeny´ na XML syntaxi. Tı´m, zˇe analyticke´ moduly budou jizˇ od pocˇa´tku prˇipraveny na zpracova´nı´ XML, nebude v budoucnu proble´m se zpracova´nı´m nove´ generace webu zalozˇene´ na XML.
3.2
Odkazy mezi dokumenty
3.2.1 XPointer – identifikace fragmentu˚ dokumentu XPointer [12] je jednoduchy´ jazyk, ktery´ umozˇnˇuje jednoznacˇnou identifikaci libovolne´ cˇa´sti dokumentu. Fakticky se jedna´ o rozsˇ´ırˇeny´ jazyk XPath. XPointer mohou s vy´hodou vyuzˇ´ıvat jednotlive´ analyticke´ moduly, ktere´ si pro zpracova´nı´ budou prˇeda´vat cˇa´sti dokumentu˚. Nebude potrˇeba prˇeda´vat cele´ cˇa´sti dokumentu˚, ale jen pomeˇrneˇ kra´tkou adresu dokumentu doplneˇnou o XPointer identifikujı´cı´ konkre´tnı´ cˇa´st dokumentu. Naprˇ´ıklad prvnı´ tabulku obsazˇenou v XML dokumentu pojmenovane´m dokument.xml, mu˚zˇeme identifikovat pomocı´ na´sledujı´cı´ho XPointeru: dokument.xml#xpointer(table[1]) XPointer mu˚zˇeme pouzˇ´ıvat pro adresova´nı´, protozˇe vsˇechny HTML stra´nky prˇeva´dı´me do XML. 3
http://www.w3.org/Status.html
19
3.2. ODKAZY MEZI DOKUMENTY
3.2.2 XLink a RDF – popis vazeb mezi stra´nkami Pro u´cˇely RAINBOW na´s zajı´majı´ i vztahy mezi jednotlivy´mi stra´nkami – naprˇ. asociace podle obsahove´ podobnosti nebo topologicke´ho usporˇa´da´nı´. Reprezentovat vztahy mezi stra´nkami mu˚zˇeme samozrˇejmeˇ mnoha zpu˚soby. Jedna z mozˇnostı´ je i vyuzˇitı´ jazyka XLink (XML Linking Language) [11], ktery´ slouzˇ´ı k za´pisu odkazu˚ mezi dokumenty. Oproti jiny´m jazyku˚m, lze v XLinku vytva´rˇet i vı´cesmeˇrne´ odkazy, ktere´ propojujı´ vı´ce stra´nek. Dalsˇ´ım du˚lezˇity´m rysem XLinku je mozˇnost prˇirˇazenı´ typu jednotlivy´m odkazu˚m. Samotne´ odkazy tak mohou prˇ´ımo ne´st neˇjakou se´mantickou informaci. Na´sledujı´cı´ uka´zka obsahuje asociace pro stra´nku zapsane´ pomocı´ XLinku: <xlink:extended xmlns:xlink=”http://www.w3.org/1999/xlink” xlink:type=”extended”> <xlink:locator xlink:href=”http://www.kosek.cz/clanky/wap/wap.html” xlink:role=”urn:x-rainbow:linkroles:basedocument” xlink:title=”Web v pr ˇı ´s ˇtı ´m tisı ´ciletı ´” xlink:type=”locator”/> <xlink:locator xlink:href=”http://www.kosek.cz/clanky/index.html” xlink:role=”urn:x-rainbow:linkroles:toc” xlink:title=”Seznam c ˇla ´nku ˚” xlink:type=”locator”/> <xlink:locator xlink:href= ”http://www.kosek.cz/clanky/wap/sluzby.html” xlink:role=”urn:x-rainbow:linkroles:next” xlink:title=”Jak budou sluz ˇby dostupne ´ uz ˇivateli” xlink:type=”locator”/> <xlink:locator xlink:href=”http://www.kosek.cz/hledej.html” xlink:role=”urn:x-rainbow:linkroles:search” xlink:title=”Fulltextove ´ prohleda ´va ´nı ´” xlink:type=”locator”/> K podobne´mu u´cˇelu mu˚zˇeme kromeˇ XLinku pouzˇ´ıt i RDF (Resource Description Format) [27]. RDF je forma´t zalozˇeny´ na XML, ktery´ umozˇnˇuje prˇipojova´nı´ libovolny´ch se´manticky´ch metadat k libovolne´mu dokumentu (informacˇnı´mu zdroji). RDF dokument umozˇnˇuje zapsat skupinu vy´roku˚, kdy je subjektu (informacˇnı´mu zdroji) prˇirˇazena jedna nebo vı´ce dvojic vlastnostı´ a jejich hodnot. Informacˇnı´ zdroje, vlastnosti i jejich hodnoty jsou identifikova´ny URI adresou. Jedinou vy´jimku tvorˇ´ı hodnota vlastnosti, ktera´ mu˚zˇe mı´t i typ textove´ho rˇeteˇzce. Vy´sˇe uvedonou informaci o asociovany´ch stra´nka´ch mu˚zˇeme klidneˇ zapsat i v RDF. http://www.kosek.cz/clanky/index.htmlhttp://www.kosek.cz/clanky/wap/sluzby.html http://www.kosek.cz/hledej.html 20
3.3. KOMUNIKACE MEZI MODULY – XML-RPC A SOAP ˇ ´ıka´, zˇe k dokumentu http://www. Vy´znam dokumentu je prˇitom celkem jasny´. R kosek.cz/clanky/wap/wap.html, existujı´ stra´nky, ktere´ jsou ve vztahu „obsah“, „dalsˇ´ı stra´nka“ a „vyhleda´vacı´ stra´nka“, a rovneˇzˇ rˇ´ıka´, jake´ to jsou stra´nky (identifikace pomocı´ jejich URI adres).
3.3
Komunikace mezi moduly – XML-RPC a SOAP
RAINBOW se skla´da´ z neˇkolika modulu˚, ktere´ mezi sebou musı´ komunikovat. Aby byl cely´ syste´m dostatecˇneˇ sˇka´lovatelny´, je potrˇeba, aby byly jednotlive´ moduly schopne´ spolupra´ce, i kdyzˇ pobeˇzˇ´ı na ru˚zny´ch pocˇ´ıtacˇ´ıch umı´steˇny´ch v sı´ti. Moduly mohou by´t navı´c implementova´ny v ru˚zny´ch jazycı´ch. Pro komunikaci bychom samozrˇejmeˇ mohli vyuzˇ´ıt takove´ technologie jako CORBA nebo DCOM, ale jejich implementace je pomeˇrneˇ slozˇita´. Existujı´ prˇitom komunikacˇnı´ protokoly zalozˇene´ na XML, ktere´ se pro nasˇe u´cˇely vy´borneˇ hodı´ a jejich implementace je mnohem jednodusˇsˇ´ı nezˇ u drˇ´ıve zmı´neˇny´ch technologiı´. Mezi nejpouzˇ´ıvaneˇjsˇ´ı a nejperspektivneˇjsˇ´ı protokoly pro komunikaci aplikacı´ dnes patrˇ´ı SOAP (Simple Object Access Protocol) [4]. Tento protokol umozˇnˇuje prˇeda´va´nı´ zpra´v ve forma´tu XML, jako komunikacˇnı´ protokol se prˇitom nejcˇasteˇji pouzˇ´ıva´ protokol HTTP (Hypertext Transfer Protocol). Na podobny´ch za´kladech stavı´ i o neˇco jednodusˇsˇ´ı protokol XML-RPC. Podrobneˇjsˇ´ı popis SOAPu je v na´sledujı´cı´ kapitole. Vy´hodou SOAPu je to, zˇe stavı´ na technologiı´ch, ktere´ jsou podporova´ny v mnoha jazycı´ch a na mnoho platforma´ch. Umozˇnˇuje proto integraci sluzˇeb, ktere´ pracujı´ v heterogennı´m a distribuovane´m prostrˇedı´.
3.4
Uzˇivatelske´ rozhranı´
Pro uzˇivatele se RAINBOW jevı´ jako navigacˇnı´ klient, ktery´ pomocı´ prˇ´ıdavne´ho okna v prohlı´zˇecˇi zprˇ´ıstupnˇuje informace o stra´nce a funkce usnadnˇujı´cı´ navigaci. Mozˇnostı´, jak vytvorˇit takove´ho klienta, je mnoho. Pomineme-li mozˇnost vytvorˇenı´ rozhranı´ jako klasicke´ho programu vyuzˇ´ıvajı´cı´ho neˇjakou knihovnu graficky´ch prvku˚ uzˇivatelske´ho rozhranı´, ma´me i neˇkolik mozˇnostı´ postaveny´ch cˇisteˇ na XML technologiı´ch. Prvnı´ mozˇnostı´ je vytvorˇenı´ rozhranı´ prˇ´ımo v HTML (prˇ´ıpadneˇ XHTML) s pouzˇitı´m JavaScriptu. Pro nasˇe u´cˇely to vsˇak nenı´ zrovna nejvhodneˇjsˇ´ı rˇesˇenı´, protozˇe HTML neobsahuje prvky pro snadne´ vytva´rˇenı´ rozbalovacı´ch seznamu˚, ktere´ jsou prˇirozeny´m zpu˚sobem pro prezentova´nı´ informacı´ v navigacˇnı´m asistentovi. Toto omezenı´ prˇekona´va´ specia´lnı´ jazyk pro tvorbu formula´rˇu˚ XForms [13]. Proble´m je v tom, zˇe tento jazyk je zatı´m jen ve stavu na´vrhu a neexistujı´ zˇa´dne´ beˇzˇneˇ pouzˇitelne´ implementace. Existujı´ vsˇak i specia´lnı´ jazyky pro deklarativnı´ popis uzˇivatelske´ho rozhranı´. Mezi nejzna´meˇjsˇ´ı patrˇ´ı jazyk XUL (XML-based User Interface Language) [21], ktery´ pouzˇ´ıva´ prohlı´zˇecˇ Mozilla4 a od neˇj odvozeny´ Netscape Navigator 6. Pomocı´ XUL mu˚zˇeme snadno vytvorˇit syste´m hierarchicky´ch nabı´dek, ktery´ zprˇ´ıstupnı´ vsˇechny navigacˇnı´ funkce. XUL ma´ tu vy´hodu, zˇe je snadno prˇenositelny´ mezi ru˚zny´mi platformami, lze jej pouzˇ´ıt vsˇude, kde pracuje Mozilla. Uzˇivatelske´ rozhranı´ je definova´no pomocı´ pojmu˚ jako dialogove´ okno, nabı´dka, polozˇka nabı´dky, seznam, vstupnı´ pole apod. 4
http://www.mozilla.org
21
˚ 3.5. XSLT – KONVERZE A TRANSFORMACE DOKUMENTU Na jednotlive´ prvky pak mu˚zˇeme nava´zat vola´nı´ ko´du v JavaScriptu nebo v C++. Toho bude vyuzˇ´ıvat i na´sˇ navigacˇnı´ klient. Interaktivnı´ chova´nı´ aplikace je zajisˇteˇno pra´veˇ pomocı´ JavaScriptu. Samotne´ rozhranı´ Mozilly je definova´no v XUL, proto mu˚zˇeme jednoduchou modifikacı´ neˇkolika souboru˚ zmeˇnit vzhled prohlı´zˇecˇe. Snadno tak mu˚zˇeme do Mozilly prˇidat dalsˇ´ı panel s rozhranı´m RAINBOW. Podrobneˇji jsou mozˇnosti Mozilly, XUL a vytvorˇenı´ navigacˇnı´ho rozhranı´ popsa´ny v kapitole 5 – Navigacˇnı´ rozhranı´ . Kdybychom kromeˇ navigacˇnı´ho rozhranı´ chteˇli vytvorˇit i vizualizacˇnı´ rozhranı´, mu˚zˇeme s vy´hodou pouzˇ´ıt jazyk SVG (Scalable Vector Graphics) [15]. Tento jazyk opeˇt zalozˇeny´ na XML syntaxi umozˇnˇuje popsat obra´zek slozˇeny´ ze za´kladnı´ch graficky´ch objektu˚ jako cˇa´ry, texty, oblouky, obde´lnı´ky, krˇivky apod. Prˇes rozhranı´ DOM pak mu˚zˇeme pomocı´ JavaScriptu s obra´zkem manipulovat a vytvorˇit interaktivnı´ graficke´ aplikace.
3.5
XSLT – konverze a transformace dokumentu˚
Pokud v jake´mkoliv veˇtsˇ´ım nezˇ male´m projektu vyuzˇ´ıva´me jazyk XML, urcˇiteˇ budeme drˇ´ıve cˇi pozdeˇji postaveni prˇed proble´m konverze mezi XML dokumenty s ru˚zny´mi sche´maty. Konverzi lze samozrˇejmeˇ implementovat pomocı´ klasicky´ch programu˚, ktere´ budou XML dokumenty cˇ´ıst prˇes neˇjake´ API jako je SAX nebo DOM. Existuje vsˇak mnohem jednodusˇsˇ´ı mozˇnost – transformacˇnı´ jazyk XSLT. XSLT (XSL Transformations) [9] je specia´lnı´ jazyk navrzˇeny´ pro transformaci XML dokumentu˚. Transformace se rˇ´ıdı´ pomocı´ stylu, ktery´ obsahuje sˇablony a mu˚zˇe se dotazovat na strukturu vstupnı´ho dokumentu. Navı´c lze pouzˇ´ıt cykly, podmı´nky a dalsˇ´ı konstrukce, ktere´ zna´me z klasicky´ch jazyku˚. Vy´sledkem transformace mu˚zˇe by´t bud’ dalsˇ´ı XML dokument, HTML stra´nka nebo libovolny´ textovy´ soubor. V syste´mech jako RAINBOW nalezne XSLT bohate´ uplatneˇnı´. Soucˇasne´ znalostnı´ syste´my ma´lokdy prˇ´ımo podporujı´ forma´t XML. Nenı´ vsˇak proble´m jaky´koliv XML dokument pomocı´ vhodne´ho stylu prˇeve´st do pozˇadovane´ho forma´tu – naprˇ. do zdrojove´ho ko´du pro interpret Prologu, textove´ho souboru pro neˇjaky´ produkt pro dolova´nı´ dat apod. V budoucnu pla´nujeme prˇida´nı´ dalsˇ´ıch koncovy´ch rozhranı´ pro uzˇivatele. Vy´sledky dotazu˚ mu˚zˇeme pomocı´ stylu konvertovat do pozˇadovane´ podoby – naprˇ. do klasicke´ HTML stra´nky, do XUL pro prohlı´zˇecˇ Mozilla nebo trˇeba do vektorove´ho graficke´ho forma´tu SVG.
3.6
Dotazovacı´ jazyky
Jelikozˇ lze do XML ukla´dat informace, je celkem logicke´, zˇe vyvstane nutnost pozdeˇji v teˇchto informacı´ch vyhleda´vat. V soucˇasne´ dobeˇ existuje pouze jediny´ skutecˇneˇ standardizovany´ jazyk pro dotazova´nı´ – XPath. Umozˇnˇuje vytva´rˇenı´ dotazu˚, ktere´ se mohou dotazovat na strukturu dokumentu a prova´deˇt navigaci po stromove´ reprezentaci XML dokumentu. XPath vsˇak nepodporuje du˚lezˇite´ funkce jako seskupova´nı´, rˇazenı´, slozˇiteˇjsˇ´ı agregacˇnı´ funkce a definice struktury vy´stupnı´ho XML. Pomineme-li pouze na´vrhy dotazovacı´ch jazyku˚, ktere´ nebyly nikdy standardizova´ny a sˇiroce prˇijaty (naprˇ. XQL a Quilt), existujı´ dnes dva hlavnı´ proudy dotazovacı´ch jazyku˚ urcˇeny´ch pro XML. Prvnı´m je snaha o rozsˇ´ırˇenı´ SQL o specia´lnı´ konstrukce podporujı´cı´ pra´ci s XML daty a jejich integraci do objektoveˇ-relacˇnı´ho modelu. V ra´mci standardizacˇnı´ skupiny
22
3.6. DOTAZOVACI´ JAZYKY pro SQL vznikla skupina SQLX,5 ktera´ pracuje na integraci XML do SQL (jedna´ se 14. cˇa´st SQL standardu tzv. SQL/XML). Projekt zahrnuje definici mapova´nı´ mezi identifika´tory a datovy´mi typy SQL a XML sche´mat, pracuje se na mozˇnosti generova´nı´ XML prˇ´ımo jako vy´sledku SQL dotazu apod. Zatı´mco SQL/XML se snazˇ´ı rozsˇ´ırˇit existujı´cı´ jazyk pro pra´ci s relacˇnı´mi a objektoveˇrelacˇnı´mi daty o mozˇnosti XML, na pu˚deˇ W3C se prˇipravuje dotazovacı´ jazyk specia´lneˇ urcˇeny´ pro dotazova´nı´ pouze nad XML dokumenty. Jazyk by meˇl v sobeˇ spojit mozˇnosti XPathu a SQL, cˇa´stecˇneˇ i s mozˇnostmi XSLT. Jedna´ se o dotazovacı´ jazyk XQuery (XML Query Language) [2]. Existuje jizˇ i neˇkolik jeho testovacı´ch implementacı´.6 V nasˇem projektu zatı´m nepocˇ´ıta´me s pouzˇitı´m komplexnı´ch dotazovacı´ch jazyku˚ jako XQuery nebo SQL/XML, naopak XPath bude vzhledem k povaze projektu pravdeˇpodobneˇ vyuzˇ´ıva´n ve velke´ mı´rˇe.
Kapitola 4 Komunikacˇnı´ infrastruktura Cely´ syste´m RAINBOW se skla´da´ z neˇkolika modulu˚, ktere´ jsou schopny prova´deˇt dı´lcˇ´ı operace – stahovat HTML stra´nky, analyzovat jejich ko´d, extrahovat metadata z HTML, lematizovat slovo apod. Tyto moduly spolu musı´ spolupracovat prˇi analy´ze stra´nek i prˇi vyhodnocova´nı´ dotazu˚. V te´to cˇa´sti pra´ce se proto podı´va´me na zpu˚soby, jaky´mi lze komunikaci vyrˇesˇit, a podrobneˇji popı´sˇeme technologii webovy´ch sluzˇeb, kterou pouzˇ´ıva´ prototypova´ implementace syste´mu.
4.1 Pozˇadavky syste´mu Prˇedtı´m nezˇ zacˇneme porovna´vat jednotlive´ technologie a techniky, ktere´ lze pouzˇ´ıt pro zajisˇteˇnı´ komunikace mezi moduly, si musı´me stanovit pozˇadavky na komunikacˇnı´ infrastrukturu.
4.1.1 Distribuovanost Prvnı´ prototypova´ implementace sice pracuje jen na jednom pocˇ´ıtacˇi, ale je velmi pravdeˇpodobne´, zˇe se v budoucnu syste´m rozroste a jednotlive´ moduly pobeˇzˇ´ı na ru˚zny´ch pocˇ´ıtacˇ´ıch. Komunikacˇnı´ infrastruktura proto musı´ umozˇnˇovat spolupra´ci modulu˚ i v distribuovane´m internetove´m prostrˇedı´.
4.1.2 Neza´vislost na implementacˇnı´m prostrˇedı´ Cˇinnost jednotlivy´ch modulu˚ je dosti rozdı´lna´ – pocˇ´ınaje cˇisteˇ technicky´mi moduly (stahova´nı´ stra´nek) azˇ po moduly implementujı´cı´ ru˚zne´ lingvisticke´ metody a metody expertnı´ch syste´mu˚. Moduly jsou navı´c vyvı´jeny ru˚zny´mi lidmi. Jednotlive´ moduly mohou by´t napsa´ny v ru˚zny´ch programovacı´ch jazycı´ch a mohou pracovat i v ru˚zny´ch operacˇnı´ch syste´mech. Komunikacˇnı´ protokol by proto nemeˇl by´t sva´za´n s neˇjaky´m konkre´tnı´m jazykem nebo platformou.
4.1.3 Flexibilita Jednotlive´ moduly majı´ dost odlisˇne´ pozˇadavky na druh prˇena´sˇeny´ch dat. Neˇkdy se prˇena´sˇejı´ jen jednoduche´ skala´rnı´ hodnoty (cˇ´ısla, rˇeteˇzce), neˇkdy cele´ HTML dokumenty, neˇkdy jen
24
4.2. MOZˇNOSTI RˇESˇENI´ KOMUNIKACE MEZI MODULY cˇa´sti HTML dokumentu˚, mu˚zˇeme uvazˇovat i o seznamech cˇi struktura´ch slozˇeny´ch z prˇedchozı´ch hodnot. Komunikacˇnı´ protokol by proto meˇl umozˇnit prˇena´sˇenı´ dat libovolne´ho druhu.
4.1.4 Asynchronnost Cˇa´st syste´mu, ktera´ bude obstara´vat komunikaci s uzˇivatelem – navigacˇnı´ rozhranı´ – si vystacˇ´ı se synchronnı´m zpu˚sobem komunikace. Uzˇivatel si do prohlı´zˇecˇe nacˇte stra´nku, tı´m vyvola´ pozˇadavek na zjisˇteˇnı´ informacı´ o stra´nce, pozˇadavek se prˇeda´ modulu˚m a ty vra´tı´ odpoveˇd’, kterou navigacˇnı´ rozhranı´ zobrazı´. Druha´ strana syste´mu, ktera´ zajisˇt’uje stahova´nı´ stra´nek a jejich analy´zu, uzˇ nemusı´ nutneˇ pracovat jen synchronneˇ. Mu˚zˇeme si prˇedstavit, zˇe se po stazˇenı´ stra´nky prˇeda´ ostatnı´m modulu˚m pozˇadavek k jejich zpracova´nı´. Toto zpracova´nı´ vsˇak mu˚zˇe probeˇhnout i za delsˇ´ı dobu a mohlo by proto pro neˇj by´t vhodneˇjsˇ´ı pouzˇ´ıt asynchronnı´ zpu˚sob komunikace, kdy jednotlive´ moduly necˇekajı´ na okamzˇity´ vy´sledek operace jako v jednoduche´m modelu pozˇadavek/odpoveˇd’. Komunikacˇnı´ infrastruktura by proto meˇla umozˇnˇovat i asynchronnı´ komunikaci, s tı´m, zˇe prototypova´ implementace syste´mu ji nejspı´sˇ zatı´m nevyuzˇije.
4.2 Mozˇnosti rˇesˇenı´ komunikace mezi moduly V soucˇasne´ dobeˇ existuje mnoho technologiı´ a postupu˚, jak po sı´ti propojit softwarove´ moduly. V na´sledujı´cı´m textu strucˇneˇ charakterizujeme nejpouzˇ´ıvaneˇjsˇ´ı metody a popı´sˇeme jejich vy´hody a nevy´hody pro pouzˇitı´ v nasˇem projektu. Rozdeˇlenı´ do kategoriı´ je prˇitom potrˇeba bra´t s jistou rezervou, jednotlive´ technologie jsou si v mnohe´m blı´zke´ a cˇasto se prˇekry´vajı´.
4.2.1
Vzda´lene´ vola´nı´ procedur
Vzda´lene´ vola´nı´ procedur (RPC – Remote Procedure Call) je jednou z nejstarsˇ´ıch metod pro komunikaci programu˚ na da´lku. RPC nabı´zı´ mechanismus, jak z jednoho programu volat funkci umı´steˇnou na vzda´lene´m syste´mu. Existuje neˇkolik protokolu˚ implementujı´cı´ch RPC – mezi nejzna´meˇjsˇ´ı patrˇ´ı asi Distributed Computing Environment (DCE).1 RPC protokol definuje zpu˚sob jak parametry a vy´sledek volane´ funkce prˇeva´deˇt do forma´tu, ve ktere´m se RPC pozˇadavky posı´lajı´ po sı´ti. Pro nasˇe potrˇeby je RPC prˇ´ılisˇ jednoduche´. Jednak RPC podporuje jen za´kladnı´ datove´ typy, prˇenos strukturovany´ch dat jako jsou naprˇ. fragmenty XML nenı´ prˇ´ımo podporova´n. Navı´c RPC prˇedpokla´da´ jednoduchy´ model pozˇadavek/odpoveˇd’, ktery´ nelze v prˇ´ıpadeˇ potrˇeby zmeˇnit na asynchronnı´ model.
4.2.2 Distribuovane´ objektove´ technologie Mezi nejzna´meˇjsˇ´ı distribuovane´ technologie patrˇ´ı bezesporu CORBA, DCOM a RMI. Ty umozˇnˇujı´ vola´nı´ vzda´leny´ch objektu˚, tak jako bychom je meˇli prˇ´ımo k dispozici. Vyuzˇ´ıva´ se prˇitom mechanismus za´stupny´ch (proxy) objektu˚. CORBA je standard vznikly´ v ra´mci 1
http://www.opengroup.org/dce/
25
4.2. MOZˇNOSTI RˇESˇENI´ KOMUNIKACE MEZI MODULY skupiny OMG a v soucˇasne´ dobeˇ existuje mapova´nı´ z jazykoveˇ neza´visle´ho popisu rozhranı´ objektu˚ IDL (Interface Definition Language) do veˇtsˇiny pouzˇ´ıvany´ch jazyku˚. DCOM je proprieta´rnı´ technologie Microsoftu, ale jeho podpora je dostupna´ rovneˇzˇ v sˇiroke´m spektru jazyku˚. RMI (Remote Method Invocation) je technologie pouzˇitelna´ pouze v jazyce Java. Ce se ty´cˇe podpory ru˚zny´ch platforem je na tom CORBA velmi dobrˇe. Modul, ktery´ zajisˇt’uje komunikaci – ORB (Object Request Broker) – je dostupny´ pro neˇkolik desı´tek platforem. Jednotlive´ ORB mezi sebou nejcˇasteˇji komunikujı´ pomocı´ protokolu IIOP (Internet Inter-ORB Protocol), ktery´ umozˇnˇuje distribuovany´ syste´m provozovat prˇ´ımo v internetove´ sı´t’ove´ infrastrukturˇe. Oproti tomu technologie DCOM vznikla prima´rneˇ pro Windows a jejı´ portace na dalsˇ´ı platformy nenı´ nijak excelentnı´. Existuje sice neˇkolik implementacı´ DCOMu pro unixove´ prostrˇedı´, ale veˇtsˇinou se jedna´ o komercˇnı´ produkty, cozˇ DCOM pro nasˇe potrˇeby prˇedem diskvalifikuje. Vyuzˇitı´ technologie CORBA by pro na´sˇ projekt bylo samozrˇejmeˇ mozˇne´. Na druhou stranu je potrˇeba rˇ´ıci, zˇe psanı´ CORBA komponent by bylo pro nasˇe u´cˇely prˇ´ılisˇ slozˇite´. CORBA nabı´zı´ i mnoho funkcı´, ktere´ v soucˇasne´ dobeˇ nepotrˇebujeme – naprˇ. transakce a vysokou bezpecˇnost.
4.2.3 Messaging Messaging je zpu˚sob komunikace mezi softwarovy´mi komponentami nebo softwarovy´mi aplikacemi zalozˇeny´ na vy´meˇneˇ zpra´v [38]. O samotne´ dorucˇova´nı´ a smeˇrova´nı´ zpra´v mezi jednotlivy´mi aplikacemi se stara´ tzv. MOM (Message Oriented Middleware). Jednotlive´ aplikace vyuzˇ´ıvajı´ sluzˇby MOM prˇes aplikacˇnı´ rozhranı´. Veˇtsˇina producentu˚ MOM syste´mu nabı´zı´ vlastnı´ API, ktere´ je dostupne´ jen pro omezeny´ pocˇet platforem. Nejveˇtsˇ´ı je dnes segment MOM syste´mu˚ pro Javu, pro kterou existuje standardnı´ API pro vyuzˇ´ıva´nı´ messagingovy´ch sluzˇeb – JMS (Java Message Service). MOM syste´my v te´ nejjednodusˇsˇ´ı podobeˇ zarucˇujı´ dorucˇenı´ zpra´vy cı´love´ aplikaci. Komunikace prˇitom probı´ha´ pomocı´ virtua´lnı´ch kana´lu˚ (tzv. destinacı´). Aplikace mu˚zˇe zpra´vy posı´lat na urcˇitou destinaci, k jejı´mu odbeˇru se mu˚zˇe prˇihla´sit jina´ aplikace (mu˚zˇe jich by´t dokonce vı´ce). Syste´my majı´ obvykle syste´m pro samotne´ dorucˇova´nı´ a smeˇrova´nı´ zpra´v oddeˇlen od aplikacˇnı´ho rozhranı´, takzˇe se o tyto detaily nemusı´me prˇ´ılisˇ starat. Kromeˇ teˇchto za´kladnı´ch funkcı´ nabı´zejı´ MOM syste´my i pokrocˇile´ funkce jako transakce (neˇkolik operacı´/zpra´v je povazˇova´no za nedeˇlitelnou operaci) a bezpecˇnost (sˇifrova´nı´ prˇena´sˇeny´ch dat, autentizace a autorizace). MOM syste´my jsou z funkcˇnı´ho hlediska hodneˇ vyspeˇle´, veˇtsˇinou se vsˇak jedna´ o komercˇnı´ produkty, cozˇ se pro na´sˇ akademicky´ projekt nehodı´. Vzhledem k tomu, zˇe v cele´m projektu RAINBOW se pouzˇ´ıva´ mnoho metod znalostnı´ho inzˇeny´rstvı´, hodneˇ jsme zvazˇovali pouzˇitı´ jazyka a protokolu KQML (Knowledge Query and Manipulation Language),2 ktery´ je de-facto standardem pro komunikaci v distribuovany´ch znalostnı´ch syste´mech. KQML je velmi obecny´ a flexibilnı´ protokol navrzˇeny´ specia´lneˇ pro komunikaci v multiagentnı´ch syste´mech. Obsahuje proto mnoho tzv. performativ, ktera´ kromeˇ samotne´ komunikace obstara´vajı´ i velke´ mnozˇstvı´ podpu˚rny´ch funkcı´ – dynamicke´ objevova´nı´ agentu˚ v syste´mu, prˇesmeˇrova´nı´ pozˇadavku˚, zjisˇteˇnı´ funkcı´ dane´ho agenta apod. V du˚sledku toho je u´plna´ implementace KQML pomeˇrneˇ slozˇita´ a jizˇ hotove´ implementace pokry´vajı´ jen velice u´zky´ okruh jazyku˚ – Java, C/C++ a Lisp. 2
http://www.cs.umbc.edu/kqml/
26
4.3. VY´ZNAM ONTOLOGIE PRˇI KOMUNIKACI Beˇhem pra´ce na projektu jsme zjisˇt’ovali mozˇnosti vyuzˇitı´ jizˇ hotove´ knihovny pro tvorbu multiagentnı´ch syste´mu˚ zalozˇeny´ch na KQML, kterou vytvorˇila Gerstnerova laboratorˇ (FEL CˇVUT) pro svu˚j syste´m ProPlanT.3 Proble´mem knihovny vsˇak byla jejı´ mala´ propustnost. Zvla´dala obsluhu jen neˇkolika zpra´v za sekundu, cozˇ pro nasˇe u´cˇely bylo opravdu ma´lo. V poslednı´ch dvou letech vyvolala velkou pozornost koncepce tzv. webovy´ch sluzˇeb (webservices). Z technologicke´ho hlediska neprˇina´sˇejı´ webove´ sluzˇby nic prˇevratneˇ nove´ho a za technologiemi jako je MOM dokonce silneˇ pokulha´vajı´ svou funkcˇnostı´ a rychlostı´. Velkou vy´hodou webovy´ch sluzˇeb je vsˇak jejich schopnost velmi levneˇ integrovat aplikace napsane´ v ru˚zny´ch jazycı´ch a bezˇ´ıcı´ch na ru˚zny´ch platforma´ch. Je toho dosazˇeno tı´m, zˇe aplikace spolu komunikujı´ posı´la´nı´m XML zpra´v pomocı´ HTTP protokolu. Podpora HTTP a XML je sˇiroce dostupna´, a proto jsou i webove´ sluzˇby dostupne´ v podstateˇ vsˇude. Za´kladem webovy´ch sluzˇeb je protokol SOAP (Simple Object Access Protocol) [4], ktery´ definuje strukturu zpra´v a zpu˚sob, jaky´m se do XML ko´dujı´ beˇzˇne´ datove´ typy. Nejcˇasteˇji se dnes v SOAPu pouzˇ´ıva´ synchronnı´ komunikace. Klientska´ aplikace posˇle v XML pozˇadavek webove´ sluzˇbeˇ (serveru), ta deko´duje pozˇadavek v XML, zavola´ prˇ´ıslusˇny´ ko´d, a vy´sledek opeˇt ve forma´tu XML zasˇle zpeˇt klientovi. Popis rozhranı´ webove´ sluzˇby (kde je sluzˇba k dispozici, jake´ ma´ vstupnı´/vy´stupnı´ parametry) je mozˇne´ forma´lneˇ specifikovat pomocı´ popisu v jazyce WSDL (Web Services Description Language) [22]. Pro mnoho jazyku˚ existujı´ knihovny, ktere´ jsou z WSDL popisu schopne´ automaticky generovat klientsky´ ko´d, ktery´ umozˇnı´ pohodlne´ vola´nı´ webove´ sluzˇby stejneˇ jako by to byla loka´lneˇ dostupna´ funkce nebo metoda. Pra´veˇ mozˇnost pouzˇitı´ webovy´ch sluzˇeb naprˇ´ıcˇ platformami a dostupnost knihoven usnadnˇujı´cı´ch implementaci byla asi hlavnı´m du˚vodem, procˇ jsme se nakonec rozhodli v projektu RAINBOW pouzˇ´ıt jako komunikacˇnı´ infrastrukturu pra´veˇ protokol SOAP. Navı´c je protokol vystaven nad XML a mu˚zˇeme si na rea´lne´m projektu vyzkousˇet praktickou pouzˇitelnost noveˇ vznikajı´cı´ technologie. Podrobneˇjsˇ´ı popis webovy´ch sluzˇeb a SOAPu naleznete v dalsˇ´ı cˇa´sti te´to kapitoly.
4.3
Vy´znam ontologie prˇi komunikaci
Ontologie [42], [37] je explicitneˇ specifikovana´ konceptualizace. Ontologie popisuje urcˇitou oblast za´jmu (dome´nu) forma´lnı´m zpu˚sobem – definuje trˇ´ıdy objektu˚, ktere´ se v dane´ oblasti nacha´zejı´, a vztahy, ktere´ mezi nimi mohou existovat. Vy´znam ontologie spocˇ´ıva´ prˇedevsˇ´ım v usnadneˇnı´ komunikace mezi lidmi, zlepsˇenı´ spolupra´ce softwarovy´ch syste´mu˚ a ve zdokonalenı´ syste´move´ho inzˇeny´rstvı´. Ontologie do vsˇech teˇchto oblastı´ prˇina´sˇejı´ mozˇnost sjednocenı´ pohledu, udrzˇenı´ konzistence a jednoznacˇnosti. Z dlouhodobe´ho hlediska se v syste´mu RAINBOW pocˇ´ıta´ s vytvorˇenı´m ontologie, ktera´ by pokry´vala dome´nu nasˇeho proble´mu – prˇedevsˇ´ım by umozˇnila klasifikaci objektu˚, se ktery´mi pracujeme, jako jsou HTML stra´nka, HTML element, text, veˇta, URL adresa apod. Prˇi veˇtsˇ´ım pocˇtu modulu˚, ktere´ by si vymeˇnˇovaly slozˇiteˇjsˇ´ı informace, je ontologie velmi du˚lezˇita´, protozˇe usnadnı´ a zjednoznacˇnı´ popis dat vymeˇnˇovany´ch mezi moduly. Kdyby se syste´m rozrostl do veˇtsˇ´ıch rozmeˇru˚ a skla´dal by se z velke´ho mnozˇstvı´ neza´visly´ch modulu˚, ktere´ by mohly by´t do syste´mu prˇida´va´ny i dynamicky, bylo by pouzˇitı´ ontologie (nebo jine´ho obdobne´ho na´stroje) v podstateˇ nevyhnutelne´. V dynamicky se meˇnı´cı´m syste´mu je nutne´ jednotlive´ zpra´vy posı´lane´ mezi moduly a jejich obsah prˇesneˇ se´manticky 3
4.4. VYUZˇITI´ WEBOVY´CH SLUZˇEB A PROTOKOLU SOAP PRˇI KOMUNIKACI oznacˇit. Jen tak mu˚zˇe by´t zarucˇeno, zˇe bude komunikace probı´hat mezi spra´vny´mi moduly, a zˇe data nebudou chybneˇ interpretova´na. V soucˇasne´ dobeˇ je mnozˇstvı´ modulu˚ v syste´mu RAINBOW minima´lnı´ a navı´c jsou moduly velmi jednoduche´. Cely´ syste´m je staticky´ a nemeˇnny´. Pouzˇitı´ forma´lnı´ ontologie by v tuto chvı´li neprˇineslo zˇa´dny´ podstatny´ uzˇitek. Samozrˇejmeˇ, zˇe i tak jsou moduly vyvı´jeny na za´kladeˇ neforma´lnı´ ontologie, kterou autorˇi vsˇech modulu˚ nosı´ ve sve´ hlaveˇ. V urcˇite´ fa´zi projektu RAINBOW se pocˇ´ıta´ s prˇida´nı´m se´manticky´ch rolı´ odkazujı´cı´ch na ontologii do vsˇech zpra´v.
4.4
Vyuzˇitı´ webovy´ch sluzˇeb a protokolu SOAP prˇi komunikaci
Jak jsme jizˇ naznacˇili, webove´ sluzˇby umozˇnˇujı´ jednoduchou komunikaci mezi aplikacemi ve velmi heterogennı´m prostrˇedı´, protozˇe komunikace je zalozˇena na platformeˇ neza´visly´ch standardech – prˇedevsˇ´ım na jazyce XML a protokolu HTTP. Aplikace si mezi sebou posı´lajı´ XML zpra´vy, ktere´ prˇena´sˇejı´ dotazy a odpoveˇdi jednotlivy´ch aplikacı´. Cela´ infrastruktura webovy´ch sluzˇeb je zalozˇena na trˇech za´kladnı´ch technologiı´ch [39]: • SOAP (Simple Object Access Protocol) – protokol pouzˇ´ıvany´ pro komunikaci; • WSDL (Web Services Description Language) – standardnı´ forma´t pro popis rozhranı´ webove´ sluzˇby; • UDDI (Universal Description, Discovery and Integration) – standardnı´ mechanismus umozˇnˇujı´cı´ registraci a vyhleda´va´nı´ webovy´ch sluzˇeb. Vza´jemne´ vztahy mezi teˇmito trˇemi technologiemi jsou zachycene´ na obra´zku 4.1. Ke kazˇde´ webove´ sluzˇbeˇ by meˇl by´t k dispozici jejı´ forma´lnı´ popis v jazyce WSDL. Z tohoto popisu jizˇ jde automaticky vygenerovat soapovy´ pozˇadavek. Ve veˇtsˇ´ıch syste´mech nebo prˇ´ımo v otevrˇene´m prostrˇedı´ Internetu se popis sluzˇby mu˚zˇe zaregistrovat do UDDI registru. Ten slouzˇ´ı jako jaky´si telefonnı´ seznam („zlate´ stra´nky“), ktery´ umozˇnˇuje vyhleda´va´nı´ sluzˇeb s urcˇity´mi parametry. Klient, ktery´ chce vyuzˇ´ıt webovou sluzˇbu, zı´ska´ bud’ prˇes UDDI, nebo prˇ´ımo jejı´ popis. Z neˇj je jasne´, jakou strukturu ma´ mı´t soapova´ zpra´va a kam se ma´ webove´ sluzˇbeˇ poslat, aby ji rozpoznala.
4.4.1
SOAP
SOAP je protokol pro posı´la´nı´ zpra´v XML a je za´kladem webovy´ch sluzˇeb. Ostatnı´ standardy jako WSDL a UDDI vznikly azˇ pozdeˇji po uvedenı´ SOAPu a jen da´le rozsˇirˇujı´ jeho mozˇnosti a snadnost pouzˇitı´. SOAP umozˇnˇuje zasla´nı´ XML zpra´vy mezi dveˇma aplikacemi a pracuje tedy na principu peer-to-peer. Zpra´va je jednosmeˇrny´ prˇenos informace od odesı´latele k prˇ´ıjemci, ale dı´ky kombinova´nı´ neˇkolika zpra´v mu˚zˇeme pomocı´ SOAPu snadno implementovat beˇzˇne´ komunikacˇnı´ sce´na´rˇe. Nejcˇasteˇji se SOAP pouzˇ´ıva´ jako na´hrada vzda´lene´ho vola´nı´ procedur (RPC), tedy v modelu pozˇadavek/odpoveˇd’. Jedna aplikace posˇle v XML zpra´veˇ pozˇadavek druhe´ aplikaci, tak pozˇadavek obslouzˇ´ı a vy´sledek zasˇle jako druhou zpra´vu zpeˇt pu˚vodnı´mu inicia´torovi komunikace. V tomto prˇ´ıpadeˇ by´va´ webova´ sluzˇba vyvola´na webovy´m serverem, ktery´ cˇeka´ 28
4.4. VYUZˇITI´ WEBOVY´CH SLUZˇEB A PROTOKOLU SOAP PRˇI KOMUNIKACI
klinet využívající webovou službu
SOAP
webová služba
komunikace pomocí XML zpráv hledání služby
popisuje rozhraní služby
popis rozhraní služby
WSDL UDDI registr
odkaz na popis služby
Obra´zek 4.1: Vztah trˇ´ı za´kladnı´ch technologiı´ (SOAP, WSDL a UDDI) webovy´ch sluzˇeb
na pozˇadavky klientu˚ a v okamzˇiku, kdy prˇes HTTP prˇijde soapova´ zpra´va, spustı´ webovou sluzˇbu a prˇeda´ jı´ pozˇadavek. Vy´sledek sluzˇby je pak prˇeda´n zpeˇt klientovi jako odpoveˇd’. Prvnı´ verze (1.0) protokolu SOAP vznikla na konci roku 1999 jako vy´sledek spolecˇne´ pra´ce firem DevelopMentor, Microsoft a UserLand, ktere´ chteˇly vytvorˇit protokol pro vzda´lene´ vola´nı´ procedur (RPC) zalozˇeny´ na XML [3]. Protokol navazoval na o rok mladsˇ´ı, jednodusˇsˇ´ı a me´neˇ flexibilnı´ protokol XML-RPC.4 V pru˚beˇhu roku 2000 se k podporˇe prˇihla´sila i firma IBM a nova´ verze SOAPu 1.1 byla zasla´na W3C konsorciu [4]. Verze SOAPu 1.1 je dnes nejpouzˇ´ıvaneˇjsˇ´ı a v diplomove´ pra´ci se budeme zaby´vat pra´veˇ jı´. Na pu˚deˇ W3C konsorcia nynı´ probı´ha´ pra´ce na uvolneˇnı´ prvnı´ho skutecˇne´ho standardu SOAP 1.2 v ra´mci pracovnı´ skupiny pro XML protokol.5 Pracovnı´ verze specifikace je dostupna´ v [17]. 4.4.1.1
Struktura zpra´vy
Zpra´va v SOAPu je jednoduchy´ XML dokument, ktery´ ma´ korˇenovy´ element Envelope. V te´to oba´lce jsou pak uzavrˇeny dva elementy Header (hlavicˇka) a Body (teˇlo). Hlavicˇka je prˇitom nepovinna´ a pouzˇ´ıva´ se pro prˇenos pomocny´ch informacı´ pro zpracova´nı´ zpra´vy – naprˇ´ıklad identifikaci uzˇivatele, autentizacˇnı´ informace (jme´no, heslo) apod. O to nejdu˚lezˇiteˇjsˇ´ı se stara´ teˇlo zpra´vy, v neˇmzˇ se prˇena´sˇejı´ informace identifikujı´cı´ volanou sluzˇbu a prˇeda´vane´ parametry, resp. na´vratove´ hodnoty sluzˇby. SOAP pouzˇ´ıva´ jmenne´ prostory pro identifikova´nı´ jednotlivy´ch cˇa´stı´ XML zpra´vy. Oba´lka, hlavicˇky a teˇlo zpra´vy patrˇ´ı do jmenne´ho prostoru http://schemas.xmlsoap.org/soap/envelope/. Prˇ´ıklad 4.1: Uka´zka jednoduche´ zpra´vy SOAP <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” 4 5
http://www.xmlrpc.com/ http://www.w3.org/2002/ws/
29
4.4. VYUZˇITI´ WEBOVY´CH SLUZˇEB A PROTOKOLU SOAP PRˇI KOMUNIKACI
SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=”urn:x-example:services:StockQuote”> <symbol>MOT Prˇ´ıklad 4.1 ukazuje velmi jednoduchy´ SOAP pozˇadavek na zjisˇteˇnı´ poslednı´ho zna´me´ho kurzu akcie s ko´dem MOT. Uka´zkova´ zpra´va pro jednoduchost neobsahuje hlavicˇku, ale pouze teˇlo. V neˇm je pozˇadavek na vyvola´nı´ vzda´lene´ funkce GetLastTradePrice s parametrem pojmenovany´m symbol s hodnotou MOT (ko´d akciı´ firmy Motorola). Jak by mohla vypadat XML zpra´va s vy´sledkem prˇiblizˇuje prˇ´ıklad 4.2. Oba dva prˇ´ıklady jsou drobneˇ modifikovane´ uka´zky prˇ´ımo z [4]. Prˇ´ıklad 4.2: Uka´zka zpra´vy s odpoveˇdı´ <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m=”urn:x-example:services:StockQuote”> 14.5 4.4.1.2
Ko´dova´nı´ dat
V uka´zka´ch SOAP zpra´v je pouzˇit jesˇteˇ jeden jmenny´ prostor – http://schemas. xmlsoap.org/soap/encoding/. Ten identifikuje zpu˚sob ko´dova´nı´ prˇena´sˇeny´ch dat do XML. Se SOAPem mu˚zˇeme pouzˇ´ıt libovolny´ zpu˚sob serializace, standard SOAPu jeden rovnou definuje. Standardnı´ serializace je schopna´ do XML prˇeve´st graf obsahujı´cı´ otypovane´ objekty. V praxi se nejcˇasteˇji pouzˇ´ıvajı´ beˇzˇne´ skala´rnı´ datove´ typy (jako cˇ´ısla, rˇeteˇzce apod.), ktere´ definujı´ XML sche´mata. Navı´c soapove´ ko´dova´nı´ definuje zpu˚sob serializace slozˇeny´ch datovy´ch typu˚ – seznamu˚ skala´rnı´ch hodnot (polı´) a struktur. Lze serializovat i reference na objekty. Obecneˇ platı´, zˇe se hodnoty ukla´dajı´ vzˇdy jako obsah elementu˚, jedna hodnota do jednoho elementu. Datove´ typy mohou by´t definova´ny bud’ v externı´m XML sche´matu nebo prˇ´ımo v XML zpra´veˇ. Druhy´ zpu˚sob je jednodusˇsˇ´ı a tedy i pouzˇ´ıvaneˇjsˇ´ı. Naprˇ. me´ osobnı´ u´daje by mohly by´t zako´dova´ny do XML pro potrˇeby SOAPu na´sledujı´cı´m zpu˚sobem: <jme ´no xsi:type=”xsd:string”>Jirka Kosek <email xsi:type=”xsd:string”>[email protected]26 Prˇedpokla´da´me prˇitom, zˇe prefixy xsi a xsd jsou sva´za´ny se jmenny´m prostorem http://www.w3.org/2001/XMLSchema-instance, resp. http://www.w3.org/ 2001/XMLSchema. Odpovı´dajı´cı´ samostatne´ XML sche´ma by pak vypadalo na´sledovneˇ: 30
4.4. VYUZˇITI´ WEBOVY´CH SLUZˇEB A PROTOKOLU SOAP PRˇI KOMUNIKACI
Jelikozˇ se dnes SOAP typicky pouzˇ´ıva´ pro RPC vola´nı´, je celkem prˇirozene´, zˇe se pro prˇenos pozˇadavku/odpoveˇdi nejcˇasteˇji pouzˇ´ıva´ protokol HTTP (HyperText Transfer Protocol) [16]. Du˚vodem je zejme´na sˇiroka´ podpora HTTP v ru˚zny´ch aplikacı´ch. Navı´c webovou sluzˇbu lze nahra´t prˇ´ımo na beˇzˇny´ webovy´ server, jenzˇ slouzˇ´ı jako „dispecˇer“, ktery´ jednotlive´ pozˇadavky prˇeda´va´ odpovı´dajı´cı´ webove´ sluzˇbeˇ ke zpracova´nı´. Vy´hoda pouzˇitı´ HTTP take´ spocˇ´ıva´ v tom, zˇe sta´vajı´cı´ sı´t’ova´ infrastruktura, zvla´sˇteˇ ve firemnı´ sfe´rˇe, dovoluje v podstateˇ neomezenou komunikaci na portu vyhrazene´m pro HTTP (TCP port 80). Webove´ sluzˇby je mozˇne´ pouzˇ´ıvat bez nutnosti za´sahu do konfigurace aktivnı´ch sı´t’ovy´ch prvku˚ jako jsou firewally. Prˇi pouzˇitı´ technologiı´ DCOM nebo CORBA je potrˇeba povolit komunikaci na portech, ktere´ pouzˇ´ıvajı´ prˇ´ıslusˇne´ prˇenosove´ protokoly (naprˇ. IIOP pro CORBA). SOAP pozˇadavek se zası´la´ v teˇle HTTP pozˇadavku. Pouzˇ´ıva´ se prˇitom metoda POST, ktera´ dovoluje posı´lat data v teˇle HTTP pozˇadavku. Pozˇadavek musı´ obsahovat HTTP hlavicˇku SOAPAction, ktera´ identifikuje SOAP pozˇadavek. Tuto hlavicˇku mohou pouzˇ´ıvat jednak firewally k filtrova´nı´ pozˇadavku˚ a jednak mu˚zˇe obsahovat URI s identifikacı´ sluzˇby, ktera´ se ma´ vyvolat. Pokud je obsahem hlavicˇky pra´zdny´ rˇeteˇzec, sluzˇba ke spusˇteˇnı´ je identifikova´na prˇ´ımo adresou, na kterou smeˇrˇuje pozˇadavek. Prˇ´ıklad 4.3: SOAP pozˇadavek zaslany´ prˇes HTTP POST /StockQuote HTTP/1.1 Content-Type: text/xml; charset=utf-8 Content-Length: nnn SOAPAction: ”” <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=”urn:x-example:services:StockQuote”> <symbol>MOT Odpoveˇd’ na pozˇadavek nema´ prˇi prˇenosu pomocı´ HTTP zˇa´dne´ prˇ´ıdavne´ informace. Obsah odpoveˇdi musı´ by´t identifikova´n jako XML dokument pomocı´ prˇ´ıslusˇne´ho MIME typu text/xml v hlavicˇce Content-Type. Prˇ´ıklad 4.4: SOAP odpoveˇd’ prˇena´sˇena´ pomocı´ HTTP HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn 31
4.4. VYUZˇITI´ WEBOVY´CH SLUZˇEB A PROTOKOLU SOAP PRˇI KOMUNIKACI
<SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m=”urn:x-example:services:StockQuote”> 14.5 Dalsˇ´ı mozˇnostı´, jak posı´lat SOAP zpra´vy pomocı´ HTTP, je vyuzˇitı´ rozsˇirˇujı´cı´ho syste´mu pro HTTP popsane´ho v [32]. Pozˇadavek a odpoveˇd’ se pak drobneˇ lisˇ´ı v hlavicˇka´ch, jak ukazujı´ prˇ´ıklady 4.5 a 4.6. Prˇ´ıklad 4.5: SOAP pozˇadavek zaslany´ prˇes rozsˇ´ırˇenı´ HTTP M-POST /StockQuote HTTP/1.1 Man: ”http://schemas.xmlsoap.org/soap/envelope”; ns=42 Content-Type: text/xml; charset=utf-8 Content-Length: nnn 42-SOAPAction: ”” <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m=”urn:x-example:services:StockQuote”> <symbol>MOT Prˇ´ıklad 4.6: SOAP odpoveˇd’ prˇena´sˇena´ pomocı´ rozsˇ´ırˇenı´ HTTP HTTP/1.1 200 OK Ext: Content-Type: text/xml; charset=utf-8 Content-Length: nnn <SOAP-ENV:Envelope xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/” SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m=”urn:x-example:services:StockQuote”> 14.5 32
4.4. VYUZˇITI´ WEBOVY´CH SLUZˇEB A PROTOKOLU SOAP PRˇI KOMUNIKACI
Jednotlive´ implementace webovy´ch sluzˇeb podporujı´ i dalsˇ´ı prˇenosove´ mechanismy. Patrˇ´ı mezi neˇ naprˇ´ıklad prˇenos pomocı´ e-mailovy´ch zpra´v pomocı´ protokolu SMTP (Simple Mail Transfer Protocol) nebo pomocı´ javove´ messagingove´ sluzˇby JMS.
4.4.2
WSDL
Jazyk WSDL [22] slouzˇ´ı k popisu sı´t’ovy´ch sluzˇeb jako mnozˇiny koncovy´ch bodu˚ zpracova´vajı´cı´ch zpra´vy. Operace a zpra´vy jsou popisova´ny na abstraktnı´ u´rovni a teprve pote´ jsou sva´za´ny s konkre´tnı´m sı´t’ovy´m protokolem a datovy´m forma´tem. To umozˇnˇuje snadne´ vytvorˇenı´ popisu rozhranı´, ktere´ nabı´zı´ jednu sluzˇbu neˇkolika zpu˚soby. V praxi WSDL popisy nejcˇasteˇji popisujı´ sluzˇby, ktere´ si posı´lajı´ zpra´vy pomocı´ forma´tu SOAP a protokolu HTTP. WSDL vzniklo jako spolecˇna´ iniciativa firem Microsoft a IBM, ktere´ si uveˇdomily potrˇebu sjednocenı´ jazyka pouzˇ´ıvane´ho pro popis rozhranı´ webovy´ch sluzˇeb. Navazuje tak na prˇedchozı´ aktivity, zejme´na na jazyky NASSL (Network Accessable Service Specification Language), SCL (SOAP Contract Language) a SDL (Service Description Language). WSDL [22] je v soucˇasne´ dobeˇ vyda´n jako informativnı´ pozna´mka W3C a v ra´mci pracovnı´ skupiny pro popis webovy´ch sluzˇeb6 se pracuje na vytvorˇenı´ skutecˇne´ho standardu. WSDL soubor s definicı´ rozhranı´ sluzˇby je XML dokument. Skla´da´ se zejme´na z na´sledujı´cı´ch elementu˚, ktere´ tvorˇ´ı za´kladnı´ cˇa´sti kazˇde´ho WSDL popisu. types Obsahuje definici datovy´ch struktur pouzˇ´ıvany´ch ve zpra´va´ch. K definici lze pouzˇ´ıt teoreticky libovolny´ typovy´ syste´m, ale nejcˇasteˇji se pouzˇ´ıvajı´ XML sche´mata. Na´stroje pro webove´ sluzˇby se starajı´ o mapova´nı´ datovy´ch typu˚ podle XML sche´mat na nativnı´ datove´ typy pouzˇite´ho jazyka. message Definuje forma´t prˇeda´vany´ch zpra´v pomocı´ drˇ´ıve definovany´ch datovy´ch typu˚. Zpra´vy fungujı´ jako vstupnı´ anebo vy´stupnı´ struktury pro operace. Kazˇda´ zpra´va se mu˚zˇe skla´dat z neˇkolika logicky´ch cˇa´stı´ s vlastnı´m datovy´m typem. Prˇi pouzˇitı´ SOAPu pro RPC odpovı´da´ jedna cˇa´st zpra´vy jednomu parametru vzda´lene´ metody. operation Abstraktnı´ definice operacı´, ktere´ jsou sluzˇbou podporova´ny. U operace se definuje jake´ ma´ vstupy a vy´stupy. Vstup a vy´stup je popsa´n jizˇ existujı´cı´ zpra´vou (message). V SOAP RPC modelu odpovı´da´ operace metodeˇ. portType Sdruzˇuje dohromady neˇkolik operacı´. binding Slouzˇ´ı pro nava´za´nı´ urcˇite´ho typu portu (portType) na konkre´tnı´ protokol a forma´t prˇenosu zpra´v. port Jeden koncovy´ bod sluzˇby definovany´ jako kombinace sı´t’ove´ adresy a drˇ´ıve definovane´ vazby (binding). service Sdruzˇuje neˇkolik koncovy´ch bodu˚ (portu˚) do jedne´ sluzˇby. 6
UDDI nabı´zı´ mechanismy pro registrova´nı´, kategorizova´nı´ a vyhleda´va´nı´ webovy´ch sluzˇeb. UDDI funguje jako velky´ adresa´rˇ, ktery´ obsahuje informace o subjektech (firma´ch) a jimi poskytovany´ch sluzˇba´ch. Samotny´ registr pracuje rovneˇzˇ jako webova´ sluzˇba a komunikace s nı´ tedy opeˇt probı´ha´ pomocı´ SOAPu. UDDI registr obsahuje na´sledujı´cı´ cˇtyrˇi druhy entit: podnikatelske´ entity (firmy) – business entity U kazˇde´ firmy v registru jsou zaznamena´ny za´kladnı´ u´daje jako na´zev, strucˇny´ popis a kontaktnı´ u´daje. Kazˇde´ firmeˇ mohou by´t prˇirˇazeny klasifikacˇnı´ identifika´tory, ktere´ urcˇujı´ oblasti jejı´ho podnika´nı´ a geografickou polohu. sluzˇby – business service Ke kazˇde´ firmeˇ jsou v registru ulozˇeny seznamy sluzˇeb, ktere´ firma poskytuje. Kazˇda´ sluzˇba je opeˇt popsa´na a obsahuje seznam sˇablon vazeb, ktere´ ukazujı´ na technicke´ u´daje nutne´ pro vyuzˇitı´ sluzˇby. sˇablony vazeb – binding template Sˇablony popisujı´, jak a kde je mozˇne´ se sluzˇbou komunikovat. Typicky je tato informace popsa´na odkazem na WSDL soubor s definicı´ rozhranı´ sluzˇby. Kazˇda´ sˇablona kromeˇ toho odkazuje na typ sluzˇby, ktery´ implementuje. typy sluzˇeb – service typ Typ sluzˇby definuje abstraktnı´ sluzˇbu. Funguje tedy jako obdoba rozhranı´, jak je zna´me naprˇ. z Javy. Neˇkolik firem mu˚zˇe nabı´zet stejny´ druh sluzˇby se stejny´m rozhranı´m a tedy i typem sluzˇby. Typ sluzˇby je popsa´n tzv. technicky´m modelem (tModel). 35
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY Typicka´ pra´ce s UDDI probı´ha´ tak, zˇe vy´voja´rˇ prohleda´ registr a najde si sluzˇby, ktere´ potrˇebuje. Zı´ska´ pro neˇ popis WSDL a mu˚zˇe je zacˇ´ıt rovnou pouzˇ´ıvat. Dodejme jesˇteˇ, zˇe UDDI nemusı´ obsahovat jen popisy webovy´ch sluzˇeb ve WSDL, lze do neˇj ukla´dat popisy sluzˇeb v libovolne´m forma´tu. Z du˚vodu interoperability se vsˇak spolecˇneˇ s UDDI pouzˇ´ıva´ pra´veˇ SOAP a WSDL. Vzhledem k tomu, zˇe na´sˇ projekt nenı´ tak rozsa´hly´ a zatı´m neobsahuje nijak velke´ mnozˇstvı´ sluzˇeb, nebudeme zatı´m UDDI registr potrˇebovat. Nebudu se jı´m proto ani podrobneˇji da´le zaby´vat.
4.5 Uka´zka vytvorˇenı´ a pouzˇitı´ jednoduche´ webove´ sluzˇby Na zacˇa´tku kapitoly jsem dosˇel k za´veˇru, zˇe pouzˇitı´ webovy´ch sluzˇeb bude pro na´sˇ projekt asi nejlepsˇ´ı, mimo jine´ z du˚vodu snadne´ho pouzˇitı´. Veˇtsˇineˇ cˇtena´rˇu˚ vsˇak asi soapove´ zpra´vy ani WSDL popisy nebudou prˇipadat zrovna pru˚hledne´ a jednoduche´. Nezby´va´ s nimi nezˇ souhlasit. Pravdou vsˇak je, zˇe od technicky´ch detailu˚ je vy´voja´rˇ veˇtsˇinou zcela odstı´neˇn dı´ky podporˇe webovy´ch sluzˇeb ve vy´vojovy´ch na´strojı´ch. Abych demonstroval snadnost pouzˇitı´ webovy´ch sluzˇeb, rozhodl jsem se do pra´ce zarˇadit popis vytvorˇenı´ a pouzˇitı´ jednoduche´ webove´ sluzˇby. Sluzˇba nesouvisı´ nijak prˇ´ımo s cı´lem projektu. Vzhledem k tomu, zˇe by tato kapitola diplomove´ pra´ce meˇla slouzˇit i jako na´vod pro tvu˚rce ostatnı´ch modulu˚ syste´mu RAINBOW, uva´dı´m zde tento jednoduchy´ prˇ´ıklad. Vytvorˇenı´ dalsˇ´ıch modulu˚ a jejich u´speˇsˇne´ zapojenı´ do komunikacˇnı´ infrastruktury je klı´cˇovy´m prˇedpokladem u´speˇsˇnosti cele´ho projektu. V Javeˇ vytvorˇ´ıme jednoduchou webovou sluzˇbu, ktera´ bude schopna´ secˇ´ıst dveˇ cˇ´ısla. Pak uka´zˇi, jak mu˚zˇeme jednodusˇe napsat klienty vyuzˇ´ıvajı´cı´ tuto sluzˇbu v Javeˇ, Perlu a C# v prostrˇedı´ .NET.
4.5.1
Vytvorˇenı´ sluzˇby
Pro vytvorˇenı´ a provozova´nı´ sluzˇby pouzˇijeme balı´k WASP (Web Applications and Services Platform)7 od firmy Systinet. Existuje mnoho dalsˇ´ıch implementacı´ webovy´ch sluzˇeb, jejich prˇehled lze nale´zt naprˇ. na adrese http://www.soapware.org/directory/4/ implementations. Nejprve si vytvorˇ´ıme jednoduchou trˇ´ıdu, ktera´ bude obsahovat metodu umozˇnˇujı´cı´ secˇtenı´ dvou cˇ´ısel (viz prˇ´ıklad 4.8). Vsˇimneˇte si, zˇe se jedna´ o zcela beˇzˇnou trˇ´ıdu, neobsahuje nic specificke´ho, co by indikovalo, zˇe se ma´ v budoucnu jednat o webovou sluzˇbu. Prˇ´ıklad 4.8: Javova´ trˇ´ıda s metodou pro soucˇet cˇ´ısel public class Soucet { public int Secti(int a, int b) { return a + b; } } 7
http://www.systinet.com/
36
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY Nynı´ chceme z te´to trˇ´ıdy udeˇlat webovou sluzˇbu. WASP pro tyto u´cˇely nabı´zı´ jednak sadu na´stroju˚ ovladatelny´ch z prˇ´ıkazove´ rˇa´dky, jednak mnohem pohodlneˇjsˇ´ı na´stroje (WASP Developer), ktere´ se integrujı´ prˇ´ımo do javove´ho vy´vojove´ho prostrˇedı´ jako je JBuilder nebo Forte.
Obra´zek 4.2: Vytvorˇenı´ webove´ sluzˇby z javove´ trˇ´ıdy
Prˇ´ımo ve vy´vojove´m prostrˇedı´ proto rˇekneme, zˇe chceme z trˇ´ıdy udeˇlat webovou sluzˇbu. Pru˚vodce prˇevodem se na´s zepta´, ktere´ metody majı´ by´t dostupne´ v ra´mci webove´ sluzˇby (obra´zek 4.3).
Obra´zek 4.3: Vy´beˇr metod prˇeva´deˇny´ch na webovou sluzˇbu
37
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY V dalsˇ´ım kroku si vybere jmenny´ prostor pro sluzˇbu, jejı´ na´zev a dalsˇ´ı parametry nezbytne´ pro spra´vne´ vygenerova´nı´ WSDL popisu (obra´zek 4.4).
Obra´zek 4.4: Nastavenı´ na´zvu webove´ sluzˇby WASP Developer na´m nynı´ vygeneroval kostru webove´ sluzˇby a za´klad WSDL souboru. Z nı´ vygenerujeme kostru instalacˇnı´ho balı´cˇku (obra´zky 4.5 a 4.6).
Obra´zek 4.5: Vygenerova´nı´ kostry instalacˇnı´ho balı´cˇku pro webovou sluzˇbu Nynı´ mu˚zˇeme prˇikrocˇit k vytvorˇenı´ plneˇ funkcˇnı´ webove´ sluzˇby. Mozˇnostı´ je mnoho, jednou z nich je vytvorˇenı´ javove´ho archivu, ktery´ obsahuje vsˇe podstatne´ provoz sluzˇby – jejı´ ko´d, WSDL popis a dalsˇ´ı konfiguracˇnı´ soubory, ktere´ vyzˇaduje WASP Server. Vytvorˇenı´ archivu je zase jen ota´zkou kliknutı´ (obra´zek 4.7). 38
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY
Tento javovy´ archiv pak mu˚zˇeme pouzˇ´ıt k instalaci webove´ sluzˇby na server. WASP Server obsahuje administracˇnı´ konzoli s webovy´m rozhranı´m. S jejı´ pomocı´ mu˚zˇeme konfigurovat existujı´cı´ sluzˇby a nove´ prˇida´vat (nahra´nı´m instalacˇnı´ho archivu – viz obra´zek 4.8). Pomocı´ administracˇnı´ho rozhranı´ (obra´zek 4.9) lze jednotlive´ sluzˇby zastavovat a spousˇteˇt, odinstalovat, prˇ´ıpadneˇ si zapnout trasova´nı´ odesı´lany´ch a prˇijı´many´ch SOAP zpra´v. Je zde k dispozici i URL adresa, kde je dostupny´ popis sluzˇby ve WSDL. S jeho znalostı´ mohou nasˇi webovou sluzˇbu vyuzˇ´ıvat i dalsˇ´ı aplikace. Prˇ´ıklad 4.9: WSDL popis uka´zkove´ webove´ sluzˇby <wsdl:definitions name=’Soucet’ 39
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY
Obra´zek 4.8: Instalace webove´ sluzˇby na server
Obra´zek 4.9: Administracˇnı´ rozhranı´ WASP Serveru
WASP nenı´ urcˇen jen pro tvorbu webovy´ch sluzˇeb, ale i pro tvorbu konzumentu˚ webovy´ch sluzˇeb. Konzument (klient) potrˇebuje pro prˇipojenı´ k webove´ sluzˇbeˇ zna´t jejı´ WSDL. WASP
41
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY Developer nabı´zı´ pru˚vodce, ktery´ je schopny´ z WSDL popisu vygenerovat vsˇechen potrˇebny´ ko´d, existujı´ samozrˇejmeˇ i na´stroje spustitelne´ z prˇ´ıkazove´ rˇa´dky. Pru˚vodce si od na´s nejprve vyzˇa´da´ URL adresu, na ktere´ lze zı´skat WSDL (obra´zek 4.10). Analy´zou WSDL jsou zjisˇteˇny vsˇechny dostupne´ sluzˇby (4.11) a mu˚zˇeme potvrdit vytvorˇenı´ ko´du pro jejich prˇ´ıstup.
Obra´zek 4.10: Generova´nı´ klienta z WSDL popisu I
Obra´zek 4.11: Generova´nı´ klienta z WSDL popisu II
42
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY V nasˇem jednoduche´m prˇ´ıpadeˇ pru˚vodce automaticky vygeneruje dva javove´ soubory. Prvnı´ obsahuje definici rozhranı´, ktere´ mapuje WSDL rozhranı´ na odpovı´dajı´cı´ javove´ rozhranı´: package client.iface; public interface Soucet { int Secti(int p0, int p1); } Druhy´ soubor obsahuje ko´d, ktery´ vytvorˇ´ı proxy objekt umozˇnˇujı´cı´ vola´nı´ metod webove´ sluzˇby. Tento ko´d mu˚zˇeme pouzˇ´ıt ve vlastnı´m programu nebo jej pouzˇ´ıt pro otestova´nı´ sluzˇby. Pro na´zornost si uka´zˇeme, jak secˇ´ıst cˇ´ısla 2 a 3 pomocı´ webove´ sluzˇby. package client; import import import import import
public class SoucetClient{ public static void main(String args[]) throws Exception { String host = ”http://localhost:6060/Soucet/”; //init the lookup WebServiceLookup lookup = (WebServiceLookup)Context.getInstance (”org.idoox.webservice.client.WebServiceLookup”); //get the instance of the Web Service interface from the lookup //change the interface class to your Web Service’s interface Soucet service = (Soucet)lookup.lookup (”http://localhost:6060/Soucet/”, Soucet.class,host); //now call the methods on your Web Service’s interface System.out.println(service.Secti(2,3)); } } Nejzajı´maveˇjsˇ´ı je poslednı´ rˇa´dka programu, kde vola´me metodu Secti() jakoby byla dostupna´ loka´lneˇ. Objekt service je prˇitom proxy objekt, ktery´ vola´nı´ metody prˇeda´ webove´ sluzˇbeˇ – postara´ se tedy o vytvorˇenı´ SOAP zpra´vy, jejı´ dorucˇenı´, prˇ´ıjem odpoveˇdi, jejı´ deko´dova´nı´ a prˇevod zpeˇt do nativnı´ch datovy´ch typu˚ Javy. Administracˇnı´ konzole WASP Serveru umozˇnˇuje zapnout sledova´nı´ SOAP komunikace. Mu˚zˇeme se pak podı´vat, jak prˇesneˇ vypadajı´ SOAP pozˇadavky/odpoveˇdi, ktere´ si klient vymeˇnˇuje se serverem. Na obra´zku 4.12 je zachycen pozˇadavek na secˇtenı´ cˇ´ısel 2 a 3. Je z neˇj jasneˇ videˇt, zˇe SOAP rozhodneˇ nenı´ optimalizova´n na velikost prˇena´sˇeny´ch dat. Pozˇadavek 43
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY i odpoveˇd’ obsahuje velke´ mnozˇstvı´ servisnı´ch informacı´. Ty vsˇak zarucˇujı´ snadne´ pouzˇitı´ webovy´ch sluzˇeb na ru˚zny´ch platforma´ch.
Obra´zek 4.12: Uka´zka SOAP komunikace mezi webovou sluzˇbou a jejı´m konzumentem
4.5.3 C# klient pro .NET .NET je nova´ platforma Microsoftu zalozˇena´ na principu podobne´m Javeˇ. Programy se nynı´ neprˇekla´dajı´ prˇ´ımo do bina´rnı´ho ko´du pro urcˇitou hardwarovou platformu a operacˇnı´ syste´m, ale prˇekla´dajı´ se do meziko´du – CIL (Common Intermmediate Language). Pro spusˇteˇnı´ programu pak musı´ by´t na pocˇ´ıtacˇi k dispozici CLR (Common Language Runtime), ktery´ se postara´ o prˇeklad CIL do nativnı´ho bina´rnı´ho ko´du a jeho spusˇteˇnı´ [40]. .NET take´ obsahuje velke´ mnozˇstvı´ knihoven s vy´bornou podporou XML a webovy´ch sluzˇeb. .NET je ostatneˇ kolem webovy´ch sluzˇeb postaven – Microsoft si uveˇdomuje potrˇebu distribuovany´ch aplikacı´ a s webovy´mi sluzˇbami je jejich implementace snazsˇ´ı nezˇ s pouzˇitı´m DCOM. Vy´vojove´ prostrˇedı´ Visual Studio .NET obsahuje na´stroje pro pohodlnou pra´ci s webovy´mi sluzˇbami. Pomocı´ jednoduche´ho pru˚vodce (4.13) na´m Visual Studio .NET vygeneruje z WSDL popisu proxy objekt. Automaticky se vytvorˇ´ı trˇ´ıda Soucet, ktera´ patrˇ´ı do jmenne´ho prostoru localhost (ten je urcˇen z adresy serveru, kde je umı´steˇna webova´ sluzˇba – v nasˇem prˇ´ıpadeˇ se jedna´ o loka´lnı´ webovy´ server). Zavola´nı´ webove´ sluzˇby je pak hracˇka: // vytvor ˇenı ´ instance proxy objektu localhost.Soucet service = new localhost.Soucet();
44
4.5. UKA´ZKA VYTVORˇENI´ A POUZˇITI´ JEDNODUCHE´ WEBOVE´ SLUZˇBY
Obra´zek 4.13: Generova´nı´ konzumenta z WSDL ve Visual Studiu .NET
Do trˇetice si uka´zˇeme vola´nı´ webove´ sluzˇby z Perlu. Pouzˇijeme prˇitom modul SOAP:Lite,8 ktery´ umozˇnˇuje vyuzˇ´ıt webove´ sluzˇby prˇ´ımo v Perlu. Knihovna opeˇt z WSDL prˇ´ımo za beˇhu programu vytvorˇ´ı proxy objekt, ve ktere´m mu˚zˇeme volat vzda´lene´ metody webove´ sluzˇby. use SOAP::Lite; print ”Program na sc ˇı ´ta ´nı ´ pr ˇes webovou sluz ˇbu\n”; print ”Zadej A: ”; $a = <STDIN>; chop($a); print ”Zadej B: ”; $b = <STDIN>; chop($b); print ”\nA + B = ”; print SOAP::Lite->service(’http://localhost:6060/Soucet/’) ->Secti($a,$b);
8
http://www.soaplite.com/
45
Kapitola 5 Navigacˇnı´ rozhranı´ Z uzˇivatelske´ho hlediska je navigacˇnı´ rozhranı´ nejdu˚lezˇiteˇjsˇ´ı cˇa´stı´ cele´ho syste´mu. V te´to kapitole se podı´va´me na funkce navigacˇnı´ho rozhranı´, mozˇnosti jejich implementace a strucˇneˇ popı´sˇeme implementaci funkcˇnı´ho prototypu navigacˇnı´ho rozhranı´.
5.1 Za´kladnı´ funkce Za´kladnı´ funkce navigacˇnı´ho rozhranı´ je velmi jednoducha´. Webovy´ prohlı´zˇecˇ by meˇl v samostatne´m okneˇ zobrazovat prˇ´ıdavne´ informace o stra´nce. Prˇi kazˇde´ zmeˇneˇ aktua´lneˇ zobrazene´ stra´nky (naprˇ´ıklad po kliknutı´ na odkaz nebo po rucˇnı´m zada´nı´ nove´ adresy) by se meˇly odpovı´dajı´cı´m zpu˚sobem aktualizovat i informace v okneˇ navigacˇnı´ho asistenta. Navigacˇnı´ rozhranı´ prˇitom prˇi kazˇde´ zmeˇneˇ nacˇtene´ stra´nky musı´ kontaktovat dotazovacı´ modul RAINBOW a vyzˇa´dat si od neˇj informace o pra´veˇ zobrazovane´ stra´nce. Dotazovacı´ modul prˇeda´ dotaz analyticky´m modulu˚m a jejich odpoveˇdi propojı´ dohromady. Vy´sledek se pak odesˇle zpeˇt do navigacˇnı´ho rozhranı´, ktere´ se postara´ o zobrazenı´.
5.2 Mozˇnosti implementace Prˇi vy´beˇru vhodne´ho implementacˇnı´ho prostrˇedı´ musı´me zva´zˇit zejme´na na´sledujı´cı´ faktory: • pohodlnost a prˇirozenost ovla´da´nı´ pro uzˇivatele; • snadnost implementace; • velikost uzˇivatelske´ skupiny, ktera´ bude moci rˇesˇenı´ vyuzˇ´ıt (naprˇ. kvu˚li omezenı´ dane´mu pouzˇitou platformou apod.).
5.2.1
Ra´my
Jedna z mozˇnostı´ implementace zcela stavı´ na mozˇnostech jazyka HTML. Ten umozˇnˇuje rozdeˇlit okno prohlı´zˇecˇe na neˇkolik cˇa´stı´ (tzv. ra´mu˚), ve ktery´ch jsou zobrazene´ samostatne´ stra´nky. V jednom ra´mu by mohlo by´t nacˇteno navigacˇnı´ rozhranı´ a ve druhe´m prohlı´zˇena´ stra´nka. Pomocı´ JavaScriptu bychom mohli detekovat zmeˇny v hlavnı´m okneˇ. Vy´hodou tohoto rˇesˇenı´ je schopnost spolupra´ce s libovolny´m webovy´m prohlı´zˇecˇem na libovolne´ platformeˇ. Samotna´ implementace by take´ nebyla prˇ´ılisˇ slozˇita´. Nevy´hodou by 46
5.3. ARCHITEKTURA PROHLI´ZˇECˇE MOZILLA vsˇak bylo teˇzˇkopa´dne´ ovla´da´nı´ pro uzˇivatele. Ten by nemohl pro zada´nı´ adresy prohlı´zˇene´ stra´nky pouzˇ´ıt klasicke´ vstupnı´ pole prohlı´zˇecˇe, ale musel by adresu psa´t do specia´lnı´ho formula´rˇe, ktery´ by nacˇetl ra´my. To je pro veˇtsˇinu uzˇivatelu˚ zcela neakceptovatelny´ postup. Navı´c nenı´ pouzˇitı´ ra´mu dostatecˇneˇ robustnı´, nebot’ mnoho komercˇnı´ch stra´nek detekuje nacˇtenı´ do ra´mu a pomocı´ JavaScriptu umı´ ra´my zrusˇit a nacˇ´ıst se do cele´ho okna.
5.2.2 Vlastnı´ prohlı´zˇecˇ Druhou extre´mnı´ mozˇnostı´ je napsa´nı´ vlastnı´ho prohlı´zˇecˇe. Veˇtsˇina prohlı´zˇecˇu˚ je dnes dostupna´ v podobeˇ komponenty (naprˇ. ActiveX), ktera´ je schopna´ zobrazovat HTML stra´nky. Stacˇ´ı tedy napsat program, ktery´ bude mı´t menu a tlacˇ´ıtka s prˇ´ıkazy zna´my´mi z beˇzˇny´ch prohlı´zˇecˇu˚ a pouzˇije jizˇ hotovou komponentu pro zobrazova´nı´ stra´nek. Do takove´ho prohlı´zˇecˇe mu˚zˇeme snadno prˇidat dalsˇ´ı panel s navigacˇnı´m rozhranı´m. Pro uzˇivatele by sice toto prostrˇedı´ mohlo by´t pomeˇrneˇ pohodlne´, zvla´sˇteˇ kdyby se na´sˇ prohlı´zˇecˇ hodneˇ podobal existujı´cı´m prohlı´zˇecˇu˚m. Existuje vsˇak jen ma´lo uzˇivatelu˚, kterˇ´ı jsou ochotni zmeˇnit svu˚j oblı´beny´ prohlı´zˇecˇ a pouzˇ´ıvat jiny´. Kdyby se meˇl na´sˇ prohlı´zˇecˇ funkcˇnostı´ prˇiblı´zˇit dnesˇnı´m prohlı´zˇecˇu˚m, nebyla by implementace prˇ´ılisˇ snadna´ ani prˇi vyuzˇitı´ jizˇ existujı´cı´ komponenty pro zobrazova´nı´ stra´nek.
5.2.3 Modifikace existujı´cı´ho prohlı´zˇecˇe Jako nejvhodneˇjsˇ´ı se nakonec jevı´ mozˇnost modifikace sta´vajı´cı´ho prohlı´zˇecˇe. Veˇtsˇina dnesˇnı´ch prohlı´zˇecˇu˚ umozˇnˇuje svou modifikaci prˇida´nı´m dalsˇ´ıch komponent. Uzˇivatel si tak nemusı´ zvykat na novou aplikaci a zpu˚sob pra´ce. Pouzˇ´ıva´ sta´le stejny´ program, ktery´ nabı´zı´ nove´ funkce dı´ky prˇ´ıdavne´ komponenteˇ. Mezi nejpouzˇ´ıvaneˇjsˇ´ı prohlı´zˇecˇe dnesˇka patrˇ´ı Internet Explorer a Netscape Navigator. Do obou prohlı´zˇecˇu˚ lze prˇidat dalsˇ´ı panely. Internet Explorer umı´ vlozˇit prˇ´ıdavny´ panel v HTML nebo jako ActiveX komponentu. Netscape Navigator, resp. jeho open source varianta Mozilla umozˇnˇujı´ vytvorˇenı´ panelu v HTML nebo ve specia´lnı´m jazyce XUL (XML User Interface Language) pro tvorbu prvku˚ uzˇivatelske´ho rozhranı´. Rozhodl jsem se panel vytvorˇit pro prohlı´zˇecˇ Mozilla. Jednak je tento prohlı´zˇecˇ dostupny´ pro mnoho platforem, a tı´m pa´dem bude i navigacˇnı´ rozhranı´ dostupne´ pro vsˇechny uzˇivatele bez rozdı´lu. Navı´c mi osobneˇ prˇipada´ jednodusˇsˇ´ı vytvorˇenı´ panelu pomocı´ jazyka XUL (je popsa´n da´le), nezˇ psanı´ specia´lnı´ ActiveX komponenty pouzˇitelne´ pouze s Internet Explorerem ve Windows.
5.3
Architektura prohlı´zˇecˇe Mozilla
Prohlı´zˇecˇ Mozilla,1 na neˇmzˇ je zalozˇen i komercˇnı´ Netscape Navigator, je zajı´mavy´ z mnoha du˚vodu˚. Jednou z jeho zvla´sˇtnostı´ je i jeho uzˇivatelske´ rozhranı´, ktere´ je popsa´no ve specia´lnı´m jazyce XUL. Dı´ky tomu lze vzhled Mozilly velice snadno meˇnit, lze do nı´ prˇida´vat dalsˇ´ı funkce a navı´c lze ja´dro Mozilly ve spojenı´ s XUL pouzˇ´ıt pro vytvorˇenı´ uzˇivatelske´ho rozhranı´ ve vlastnı´ch programech. Procˇ je vlastneˇ v Mozille pouzˇit tento poneˇkud neobvykly´ zpu˚sob vytva´rˇenı´ uzˇivatelske´ho rozhranı´? Ve veˇtsˇineˇ jazyku˚ se prˇi tvorbeˇ aplikacı´ pouzˇ´ıva´ specia´lnı´ knihovna, ktera´ 1
http://www.mozilla.org
47
5.3. ARCHITEKTURA PROHLI´ZˇECˇE MOZILLA umozˇnˇuje vytva´rˇet dialogova´ okna, vkla´dat do nich ru˚zne´ prvky uzˇivatelske´ho rozhranı´ a komunikovat s nimi. Vy´voja´rˇi aplikacı´ pro Windows nejspı´sˇe znajı´ knihovnu MFC, existujı´ i knihovny urcˇene´ pu˚vodneˇ pro Linux jako Gtk a Qt. Proble´m je vsˇak v tom, zˇe tyto knihovny podporujı´ jednu a v lepsˇ´ım prˇ´ıpadeˇ neˇkolik ma´lo platforem. Existujı´ verze knihoven Gtk a Qt urcˇene´ i pro Windows, a existujı´ i dalsˇ´ı multiplatformnı´ knihovny jako wxWindows. S veˇtsˇ´ımi cˇi mensˇ´ımi obtı´zˇemi tak lze vyvı´jet aplikace, ktere´ pu˚jde spustit na neˇkolika ma´lo platforma´ch. Kdyzˇ se vsˇak podı´va´me na stra´nky projektu Mozilla, zjistı´me, zˇe prohlı´zˇecˇ je k dispozici pro opravdu sˇirokou sˇka´lu platforem: Windows, MacOS 9, MacOS X, Linux, AIX, BeOS, OpenVMS, HPUX, FreeBSD, NetBSD, BSD/OS, Caldera OpenUNIX8, OS/2, Solaris, Irix, Tru64 Unix. Teˇzˇko bychom hledali neˇjakou knihovnu, ktera´ by umozˇnila vyvı´jet graficke´ aplikace jednotny´m zpu˚sobem pro vsˇechny tyto platformy. Mozilla podporuje opravdu mnoho platforem, a tak se jejı´ vy´voja´rˇi museli s proble´mem prˇenositelnosti vyporˇa´dat vlastnı´mi silami. Vytvorˇili prˇitom velice flexibilnı´ syste´m, ktery´ prˇina´sˇ´ı i dalsˇ´ı vy´hody. Ja´drem Mozilly je zobrazovacı´ ja´dro Gecko. To umı´ zobrazovat HTML stra´nky a podporuje samozrˇejmeˇ kaska´dove´ styly (CSS) a JavaScript. Kromeˇ HTML umı´ interpretovat i jazyk XUL, ktery´ popisuje prvky uzˇivatelske´ho rozhranı´ jako menu, okna, vstupnı´ pole, tlacˇ´ıtka apod. Mozilla, kterou vidı´me na obrazovce nasˇeho pocˇ´ıtacˇe, tedy nenı´ nic jine´ho nezˇ jedno okno, ve ktere´m Gecko zobrazuje uzˇivatelske´ rozhranı´ definovane´ pomocı´ XUL. Samotny´ XUL nijak prˇesneˇ nedefinuje vzhled rozhranı´. Barvy, zpu˚sob zarovna´nı´, velikost okraju˚ a obra´zky, ze ktery´ch se rozhranı´ skla´da´, jsou definova´ny neza´visle pomocı´ kaska´dovy´ch stylu˚. Souboru kaska´dovy´ch stylu˚ a obra´zku˚, ktere´ definujı´ vzhled urcˇite´ cˇa´sti aplikace, se rˇ´ıka´ skin. K jednomu XUL rozhranı´ mu˚zˇeme mı´t neˇkolik definic vzhledu. XUL a kaska´dove´ styly rˇesˇ´ı pouze zobrazenı´ uzˇivatelske´ho rozhranı´. Kazˇda´ smysluplna´ aplikace vsˇak musı´ reagovat na pozˇadavky uzˇivatele. Prˇ´ımo v XUL lze proto pro jednotlive´ uda´losti vyvola´vane´ uzˇivatelem definovat ko´d v JavaScriptu, ktery´ se postara´ o obsluhu uda´losti. Samozrˇejmeˇ zˇe v JavaScriptu nelze psa´t neˇjake´ velke´ a slozˇite´ aplikace. Mozilla proto obsahuje sadu neˇkolika technologiı´, ktere´ umozˇnˇujı´ pomocı´ JavaScriptu vyvola´vat nativnı´ ko´d napsany´ v C++ a dalsˇ´ıch jazycı´ch. Vsˇechny technologie, ktere´ se pouzˇ´ıvajı´ pro propojenı´ JavaScriptu s nativnı´m ko´dem, majı´ v na´zvu pı´smena „XP“, ktere´ symbolizujı´ prˇenositelnost mezi platformami. Za´kladem psanı´ prˇenositelne´ho bina´rnı´ho ko´du je XPCOM (cross-platform component object model). Jedna´ se obdobu rozhranı´ COM zna´me´ho z Windows. Pokud pı´sˇeme neˇjaky´ ko´d naprˇ´ıklad v C++, vytvorˇ´ıme pro neˇj XPCOM oba´lku, ktera´ obsahuje rozhranı´ neza´visle´ na jazyku a pouzˇite´ platformeˇ. Ostatnı´ komponenty pak mohou snadno vyuzˇ´ıvat sluzˇby nabı´zene´ tı´mto objektem. Samotny´ ko´d v C++ samozrˇejmeˇ musı´me vzˇdy prˇelozˇit pro konkre´tnı´ platformu, ale zpu˚sob vyvola´nı´ tohoto ko´du je dı´ky XPCOMu stejny´ na vsˇech syste´mech. XPIDL (cross-platform interface definition language) umozˇnˇuje popsat rozhranı´ definovana´ jednotlivy´mi objekty. Jeho syntaxe je velice blı´zka´ jazyku IDL. Pomocı´ specia´lnı´ho prˇekladacˇe pak mu˚zˇeme z XPIDL automaticky vygenerovat hlavicˇkove´ soubory a dalsˇ´ı potrˇebne´ soubory pro snazsˇ´ı vytvorˇenı´ XPCOM objektu˚. O samotne´ propojenı´ JavaScriptu a objektu˚ XPCOM se stara´ technologie XPConnect, ktere´ umozˇnˇuje prˇ´ıme´ vola´nı´ XPCOM objektu˚ z JavaScriptu a naopak. Vza´jemne´ propojenı´ jednotlivy´ch XP-technologiı´ je zachyceno na obra´zku 5.1. Jelikozˇ je Mozilla pomeˇrneˇ mlady´ projekt, byl pro jeho autory vy´beˇr syntaxe jazyka XUL pomeˇrneˇ jednoduchy´ – XUL je jazyk zalozˇeny´ na XML. Pro jednotlive´ prvky uzˇivatelske´ho rozhranı´ existujı´ odpovı´dajı´cı´ XML elementy. Chova´nı´ prvku˚ je pak ovlivnˇova´no pomocı´ 48
5.3. ARCHITEKTURA PROHLI´ZˇECˇE MOZILLA
XUL JavaScript
XPConnect XPIDL C++ XPCOM
další jazyky
Obra´zek 5.1: XP-architektura Mozilly
parametru˚, ktere´ se zapisujı´ jako XML atributy. Vzhled prvku˚ je definova´n pomocı´ kaska´dove´ho stylu. K dispozici ma´me vsˇechny beˇzˇne´ prvky uzˇivatelske´ho rozhranı´: • okna a dialogova´ okna; • menu, submenu a polozˇky menu; • prˇepı´nacı´ tlacˇ´ıtka; • zasˇkrta´vacı´ tlacˇ´ıtka; • lisˇty na´stroju˚; • textove´ popisky a obra´zky; • vstupnı´ textova´ pole; • tlacˇ´ıtka; • karty se za´lozˇkami; • pop-up menu; • seznamy a hierarchicke´ (stromove´) seznamy; • a dalsˇ´ı. Kromeˇ teˇchto standardnı´ch prvku˚ mu˚zˇeme v XULu pouzˇ´ıvat libovolne´ HTML elementy, ktere´ se do dokumentu vkla´dajı´ pomocı´ zvla´sˇtnı´ho jmenne´ho prostoru. Vza´jemne´ umı´steˇnı´ prvku˚ lze ovla´dat trˇemi zpu˚soby. Prvnı´ mozˇnostı´ je uzavı´rat skupiny prvku˚ do boxu˚, ktere´ se skla´dajı´ vedle sebe nebo nad sebe. Tento zpu˚sob je velice jednoduchy´ a pro veˇtsˇinu aplikacı´ s nı´m bohateˇ vystacˇ´ıme. Dalsˇ´ı mozˇnostı´ je pouzˇ´ıt neˇktery´ ze zabudovany´ch layout manazˇeru˚.2 Poslednı´ mozˇnostı´ je nastavit umı´steˇnı´ prvku˚ pomocı´ kaska´dove´ho stylu. 2
Layout manazˇer je neviditelna´ komponeta uzˇivatelske´ho rozhranı´, ktera´ se stara´ o vza´jemne´ rozmı´steˇnı´ ostatnı´ch komponent uzˇivatelske´ho rozhranı´.
49
5.4. IMPLEMENTACE Propojenı´ ko´du s uzˇivatelsky´mi akcemi se deˇje podobneˇ jako v HTML pomocı´ uda´lostı´. U kazˇde´ho elementu mu˚zˇeme pouzˇ´ıt specia´lnı´ atributy, ktere´ odpovı´dajı´ jednotlivy´m akcı´m provedeny´m uzˇivatelem. Hodnotou atributu bude javascriptovy´ ko´d, ktery´ se pouzˇije pro obslouzˇenı´ prˇ´ıslusˇne´ uda´losti. Jednoduche´ aplikace vystacˇ´ı pouze s JavaScriptem, ty slozˇiteˇjsˇ´ı pak zavolajı´ bina´rnı´ objekty pomocı´ XPConnectu. Mezi nejpouzˇ´ıvaneˇjsˇ´ı uda´lost patrˇ´ı oncommand, ktera´ se vyvola´va´ naprˇ. vy´beˇrem polozˇky z menu nebo stiskem tlacˇ´ıtka. V soucˇasne´ podobeˇ lze pomocı´ jazyku˚ XUL a CSS dosa´hnout oddeˇlenı´ definice rozhranı´ od jeho vzhledu. Mozilla umozˇnˇuje oddeˇlit i definici chova´nı´ rozhranı´. Novy´ jazyk XBL (Extensible Bindings Language) [20] umozˇnˇuje definovat obsluhu uda´lostı´ mimo XUL (prˇ´ıpadneˇ HTML) ko´d. Za´kladnı´ princip je prˇitom stejny´ jako prˇi pouzˇitı´ oddeˇleny´ch definic chova´nı´ (behavior), se ktery´mi prˇisˇel uzˇ Internet Explorer 5. Podobne´ zameˇrˇenı´ ma´ i standard XML events [30] vznikajı´cı´ na pu˚deˇ W3C. Kaska´dovy´ styl mu˚zˇe pro kazˇdy´ element kromeˇ prezentacˇnı´ch vlastnostı´ definovat i jme´no souboru, ktery´ obsahuje definice funkcı´ obsluhujı´cı´ch jednotlive´ uda´losti. V za´vislosti na pouzˇite´m stylu se pak mu˚zˇe zmeˇnit i chova´nı´ cele´ aplikace. I kdyzˇ lze XUL a Gecko pouzˇ´ıt pro tvorbu aplikacı´ prˇenositelny´ch mezi platformami, nemyslı´m si, zˇe by to byl hlavnı´ prˇ´ınos. Samotne´ ja´dro Mozilly, ktere´ XUL ko´d interpretuje zabere v pameˇti pomeˇrneˇ dost mı´sta, ktere´ by jinak mohla vyuzˇ´ıvat aplikace. Otevrˇena´ architektura Mozilly se podle mne vyuzˇije prˇedevsˇ´ım prˇi rozsˇirˇova´nı´ schopnostı´ prohlı´zˇecˇe. Pomocı´ XULu mu˚zˇeme jednodusˇe upravit rozhranı´ Mozilly – prˇidat okno pro aktua´lnı´ firemnı´ zpra´vy, burzovnı´ zpravodajstvı´, pohodlne´ vyhleda´va´nı´ pomocı´ navigacˇnı´ho asistenta atd. Z prohlı´zˇecˇe se tak da´ velice snadno vytvorˇit pohodlne´ prostrˇedı´ pro vstup do digita´lnı´ho komunikacˇnı´ho sveˇta.
5.4 Implementace Pro implementaci prototypu navigacˇnı´ho rozhranı´ jsem se rozhodl pouzˇ´ıt prohlı´zˇecˇ Mozilla. Ten obsahuje postrannı´ pruh (sidebar), do ktere´ho lze velmi snadno prˇidat vlastnı´ panely vytvorˇene´ v HTML nebo XUL. Panel musı´ cˇekat na zmeˇnu stra´nky zobrazene´ v hlavnı´m okneˇ prohlı´zˇecˇe. Zmeˇnu lze detekovat dveˇma zpu˚soby: • panel se zaregistruje jako specia´lnı´ komponenta, ktera´ obdrzˇ´ı uda´lost prˇi zmeˇneˇ zobrazene´ stra´nky; • panel bude v pravidelny´ch cˇasovy´ch intervalech kontrolovat, zda nedosˇlo ke zmeˇneˇ stra´nky. Prvnı´ varianta je samozrˇejmeˇ elegantneˇjsˇ´ı. Bohuzˇel ji nemu˚zˇeme pouzˇ´ıt. Klasicky nainstalovane´ panely nemohou kvu˚li bezpecˇnostnı´m omezenı´ Mozilly odposloucha´vat zmeˇny v hlavnı´m okneˇ.3 Pokud chceme, aby meˇl panel vysˇsˇ´ı opra´vneˇnı´, mu˚zˇeme ho nainstalovat pomocı´ instalacˇnı´ho balı´cˇku XPI, cozˇ je forma´t pouzˇ´ıvany´ pro instalaci prˇ´ıdavny´ch komponent Mozilly. Bohuzˇel v Mozille je dosud neodstraneˇna´ chyba, ktera´ znemozˇnˇuje instalaci vlastnı´ch komponent s vysˇsˇ´ımi pra´vy pra´veˇ do postrannı´ho panelu. Musel jsem proto pouzˇ´ıt druhe´, me´neˇ elegantnı´, rˇesˇenı´. Do panelu se vlozˇ´ı jednoduchy´ skript v JavaScriptu, ktery´ kazˇdou sekundu zjisˇt’uje pra´veˇ aktivnı´ stra´nku v hlavnı´m okneˇ. 3
Du˚vod je podle vy´voja´rˇu˚ Mozilly v ochraneˇ soukromı´ uzˇivatele. Kdyby mohl libovolny´ panel sledovat pohyb uzˇivatele po webu, jednalo by se o vy´znamny´ za´sah do jeho soukromı´.
50
5.4. IMPLEMENTACE Pokud se stra´nka zmeˇnı´, posˇle se HTTP pozˇadavek na javovy´ servlet, ktery´ slouzˇ´ı jako dotazovacı´ modul (viz obra´zek 5.2). V parametrech se posˇle URL adresa pra´veˇ nacˇtene´ stra´nky. Dotazovacı´ modul kontaktuje analyticke´ moduly a dalsˇ´ı sluzˇby, vyzˇa´da´ si od nich informace, zapı´sˇe je do hierarchicke´ podoby pomocı´ XUL, ktere´ je odesla´no zpeˇt do navigacˇnı´ho rozhranı´. Uzˇivatel tak zı´ska´ prˇ´ıdavne´ informace o pra´veˇ nacˇtene´ stra´nce.
ížeč ázková webová stránka xxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxx xxxx xxxx xxxxxx xxxxxxxx xxxxxxxxx xxxxxxx xxxx xxxxxxxxxx x x xxxxxxxx xxxxxxxx xxx ého autora
navigační rozhraní é stránky
xxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxx xxxx xxxx xxxxxx xxxxxxxx xxxxxxxxx xxxxxxx xxxx xxxxxxxxxx x x xxxxxxxx xxxxxxxx xxx xxxxxxx xxxxxxxxx xxxxxxxxx xxxxxxxxxxxxxxxxx xxxxxxxxxx xxxx xxxx xxxxxx xxxxxxxx xxxxxxxxx xxxxxxx xxxx xxxxxxxxxx x x xxxxxxxx xxxxxxxx xxx
předání dotazu pomocí HTTP protokolu při každé změně stránky URL
webový server
konzultace s externími vyhledávacími službami
Internet
webov
servlet XUL
znalosti a metadata o stránkách
Analytické moduly
Obra´zek 5.2: Sche´ma obslouzˇenı´ pozˇadavku navigacˇnı´m rozhranı´m Oproti pu˚vodnı´mu na´vrhu RAINBOW jsem v prototypove´ implementaci sloucˇil dohromady dotazovacı´ modul a modul prˇekla´dajı´cı´ vy´sledek dotazu do forma´tu vhodne´ho pro navigacˇnı´ rozhranı´. Funkcˇnı´ch analyticky´ch modulu˚ je zatı´m tak ma´lo, zˇe by bylo zbytecˇny´m zdrzˇova´nı´m a komplikova´nı´m rozdeˇlovat tuto funkcˇnost do dvou neza´visly´ch komponent. V budoucnu, azˇ bude vı´ce funkcˇnı´ch modulu˚, se toto rozdeˇlenı´ samozrˇejmeˇ provede. Servlet pak pomocı´ SOAPu bude komunikovat s dotazovacı´m modulem, ktery´ se postara´ o agregaci vy´sledku˚ z dalsˇ´ıch modulu˚ (s nimi bude opeˇt komunikovat pomocı´ SOAPu). Zdrojove´ ko´dy servletu a navigacˇnı´ho rozhranı´ naleznete v prˇ´ıloze B – Navigacˇnı´ rozhranı´ . Dotazovacı´ modul v soucˇasne´ dobeˇ pouzˇ´ıva´ externı´ vyhleda´vacı´ sluzˇbu Google4 pro zjisˇteˇnı´ souvisejı´cı´ch stra´nek a dveˇ pu˚vodnı´ sluzˇby RAINBOW pro zı´ska´nı´ metadat a indika´toru˚ stra´nky. Na obra´zcı´ch 5.35 a 5.4 si mu˚zˇete prohle´dnout navigacˇnı´ rozhranı´ v provozu.
4
Google bohuzˇel na mnoha stra´nka´ch v cˇesˇtineˇ nahradı´ znaky s diaktritikou otaznı´kem. Na´zvy neˇktery´ch stra´nek v navigacˇnı´m rozhranı´ jsou proto zkomolene´. 5 Stra´nka vedoucı´ho me´ diplomove´ stra´nce nebyla vybra´na ani na´hodneˇ, ani z vypocˇ´ıtavosti. Je jednou z ma´la, ktera´ obsahuje metadata.
51
5.4. IMPLEMENTACE
Obra´zek 5.3: Uka´zka navigacˇnı´ho rozhranı´ v provozu
Kapitola 6 Stahova´nı´ a ukla´da´nı´ stra´nek Soucˇasny´ na´vrh syste´mu RAINBOW pocˇ´ıta´ s tı´m, zˇe se zdrojove´ webove´ stra´nky prˇedzpracujı´ do podoby znalostnı´ ba´ze. Syste´m tedy bude funkcˇnı´ pouze pro omezenou cˇa´st webovy´ch stra´nek, ktere´ budou prˇedem zpracova´ny. V te´to cˇa´sti pra´ce se proto podı´va´me na zpu˚soby, jaky´mi lze z Internetu stahovat kolekce webovy´ch stra´nek pro dalsˇ´ı zpracova´nı´. Nejprve strucˇneˇ zhodnotı´me jednotlive´ prˇ´ıstupy k tomuto proble´mu a pote´ se sezna´mı´me s implementacı´ vlastnı´ho stahovacı´ho robota pouzˇite´ho v projektu RAINBOW.
6.1 Mozˇne´ prˇı´stupy ke stahova´nı´ a ukla´da´nı´ stra´nek Jesˇteˇ nezˇ mu˚zˇeme ze stra´nek zı´ska´vat neˇjake´ informace a ukla´dat je do znalostnı´ ba´ze, musı´me neˇkde stra´nky zı´skat. Dnes se pro tuto cˇinnost beˇzˇneˇ pouzˇ´ıvajı´ webovı´ roboti,1 cozˇ jsou programy, ktere´ sta´hnou zadanou webovou stra´nku a ulozˇ´ı ji. Kromeˇ toho stejny´m zpu˚sobem zpracujı´ i vsˇechny stra´nky, na ktere´ z pu˚vodnı´ stra´nky vedly odkazy. Tı´mto zpu˚sobem lze po urcˇite´ dobeˇ zı´skat podstatnou cˇa´st webovy´ch stra´nek. Veˇtsˇina robotu˚ samozrˇejmeˇ stahuje stra´nky jen z omezene´ho pocˇtu serveru˚ – naprˇ. pro u´cˇely cˇesky´ch vyhleda´vacı´ch serveru˚ roboti obvykle stahujı´ jen dokumenty z na´rodnı´ dome´ny .cz. Pokud naopak chceme zı´skat co nejvı´ce stra´nek, mu˚zˇeme z WHOIS serveru˚ obsahujı´cı´ch zaregistrovane´ dome´ny zı´skat seznam potenciona´lna´ch webovy´ch serveru˚ a pokusit se je vsˇechny zpracovat. Pro projekt RAINBOW webove´ho robota samozrˇejmeˇ potrˇebujeme. Sta´li jsme proto prˇed rozhodnutı´m, jake´ho robota pouzˇ´ıt. Prˇi rozhodova´nı´ byla nejdu˚lezˇiteˇjsˇ´ı prˇedevsˇ´ım na´sledujı´cı´ dveˇ krite´ria: • ulozˇene´ stra´nky musı´ by´t snadno prˇ´ıstupne´ pro dalsˇ´ı aplikace; • proces stahova´nı´ by meˇl jı´t ovlivnit – naprˇ. by meˇlo by´t mozˇne´ upravovat seznam povoleny´ch a zaka´zany´ch dome´n, meˇla by by´t podporova´na ru˚zna´ cˇeska´ ko´dova´nı´ apod. Pro samotne´ ulozˇenı´ stahovany´ch stra´nek se nabı´zejı´ trˇi mozˇnosti: • ulozˇenı´ do souboru˚ na disku tak, zˇe kazˇde´ stra´nce odpovı´da´ jeden soubor; • ulozˇenı´ do relacˇnı´ databa´ze tak, zˇe kazˇde´ stra´nce odpovı´da´ jeden za´znam; • ulozˇenı´ do vlastnı´ho forma´tu, kde bude vı´ce stra´nek v jednom fyzicke´m souboru. 1
Neˇkdy te´zˇ zna´mı´ pod angl. na´zvem spider nebo crawler.
53
6.1. MOZˇNE´ PRˇI´STUPY KE STAHOVA´NI´ A UKLA´DA´NI´ STRA´NEK Vy´cˇet nenı´ samozrˇejmeˇ kompletnı´. Pro ukla´da´nı´ bychom mohli vyuzˇ´ıt i neˇkterou z nativnı´ch XML databa´zı´ nebo dokumenty dekomponovat na u´rovenˇ elementu˚ a ty ukla´dat jako jednotlive´ za´znamy do relacˇnı´ databa´ze. Dekompozice na elementy pro nasˇ´ı aplikaci vsˇak neprˇina´sˇ´ı zˇa´dnou vy´hodu, spı´sˇe naopak, protozˇe veˇtsˇina dokumentu˚ pracuje s dokumentem jako s celkem. Nativnı´ XML databa´ze jsou zatı´m v pocˇa´tku sve´ho vy´voje.
6.1.1
Ukla´da´nı´ stra´nek do souboru˚
Stahova´nı´ stra´nek do souboru˚ je implementacˇneˇ nejjednodusˇsˇ´ı, protozˇe lze vyuzˇ´ıt jizˇ existujı´cı´ programy (naprˇ. WGET [44] nebo w3mir [43]). Stahova´nı´ stra´nek do souboru˚ ma´ vsˇak i na´sledujı´cı´ nevy´hody: • veˇtsˇina operacˇnı´ch syste´mu˚ ma´ limit pro pocˇet souboru˚ na disku, ktery´ se pohybuje obvykle v rˇa´du desı´tek azˇ stovek tisı´c; • nad procesem stahova´nı´ nema´me kontrolu, takzˇe nemu˚zˇeme snadno detekovat duplicitnı´ dokumenty, sjednotit ko´dova´nı´ dokumetu˚ apod.; • procesem stahova´nı´ na disk jsou zmeˇneˇny odkazy, kdy neˇktere´ vedou k dalsˇ´ım stra´nka´m na disku a neˇktere´ sta´le odkazujı´ na Internet – sestavenı´ orientovane´ho grafu zna´zornˇujı´cı´ho odkazy mezi stra´nkami je obtı´zˇne´, ne-li nemozˇne´; • pro dalsˇ´ı zpracova´nı´ a vyuzˇitı´ ostatnı´mi moduly nenı´ ulozˇenı´ do souboru˚ moc sˇikovne´.
6.1.2 Ukla´da´nı´ stra´nek do relacˇnı´ databa´ze Ukla´da´nı´ stra´nek do relacˇnı´ databa´ze si vynutı´ napsa´nı´ vlastnı´ho robota (nebo u´pravu sta´vajı´cı´ho) urcˇene´ho pro stahova´nı´ stra´nek. To vsˇak nenı´ zas tak obtı´zˇny´ u´kol. Zı´ska´me tı´m navı´c plnou kontrolu nad cely´m procesem stahova´nı´ stra´nek. Mu˚zˇeme pak detekovat naprˇ´ıklad duplicitnı´ stra´nky, sjednotit ko´dova´nı´ dokumentu˚ apod. Samotne´ vyuzˇitı´ relacˇnı´ databa´ze prˇinese na´sledujı´cı´ vy´hody: • do relacˇnı´ databa´ze lze velice snadno prˇistupovat z te´meˇrˇ libovolne´ho jazyka, nebude proto proble´m vyuzˇ´ıvat zı´skana´ data v dalsˇ´ıch analyticky´ch modulech;2 • databa´zove´ servery obvykle ukla´dajı´ vsˇechna data do jednoho souboru, proto nejsme limitova´ni pocˇtem souboru˚ (webovy´ch stra´nek); • k databa´zove´mu serveru lze prˇistupovat i vzda´leneˇ pomocı´ TCP/IP – nenı´ proble´m cely´ syste´m rozlozˇit na neˇkolik pocˇ´ıtacˇu˚. Na druhou stranu existujı´ limity pro maxima´lnı´ velikost souboru (obvykle okolo 2 GB) a neˇktere´ starsˇ´ı databa´zove´ servery obvykle neumeˇjı´ rozdeˇlit jednu tabulku nebo databa´zi do vı´ce souboru˚. 2
Pozdeˇji prˇi implementaci RAINBOW jsme se rozhodli jı´t cestou webovy´ch sluzˇeb a prˇ´ıstup ke stra´nka´m je zprostrˇedkova´n samostatnou sluzˇbou, ktera´ ostatnı´ moduly od skutecˇne´ho u´lozˇisˇteˇ stra´nek odstı´nı´.
54
6.1. MOZˇNE´ PRˇI´STUPY KE STAHOVA´NI´ A UKLA´DA´NI´ STRA´NEK
6.1.3 Ukla´da´nı´ do vlastnı´ho forma´tu Nevy´hodou databa´zove´ho serveru je, zˇe pouzˇ´ıvane´ datove´ struktury a prˇ´ıstupove´ algoritmy nejsou plneˇ optimalizova´ny pro nasˇi u´lohu. Kdybychom napsali vlastnı´ specializovanou jednou´cˇelovou databa´zi, mohli bychom dosa´hnout vysˇsˇ´ı efektivity. Na´rocˇnost te´to u´lohy, nutnost implementovat sı´t’ovy´ prˇ´ıstup apod. na´s myslı´m opravnˇujı´ pouzˇ´ıt jizˇ existujı´cı´ databa´zovy´ syste´m, ktery´ mozˇna´ bude o pa´r procent pomalejsˇ´ı a pameˇt’oveˇ na´rocˇneˇjsˇ´ı, ale usˇetrˇ´ı na´m spoustu pra´ce. Zvla´sˇteˇ pokud cely´ syste´m RAINBOW cha´peme jako prototypovou implementaci.
6.1.4 Datovy´ model pro ulozˇenı´ stra´nek Rozhodneme-li se pro ulozˇenı´ stazˇeny´ch stra´nek do databa´ze, musı´me se shodnout na datove´m modelu, ktery´ se pro ukla´da´nı´ stra´nek bude pouzˇ´ıvat. Acˇkoliv by se na prvnı´ pohled mohlo zda´t, zˇe si pro ukla´da´nı´ stra´nek vystacˇ´ıme s jednou tabulkou, opak je pravdou. Nenı´ neobvykle´, zˇe jedna stra´nka se na Webu objevuje v neˇkolika exempla´rˇ´ıch s ru˚zny´mi URL adresami.3 To je pro na´s sama o sobeˇ du˚lezˇita´ informace a navı´c na´m to umozˇnı´ usˇetrˇit mı´sto potrˇebne´ pro ulozˇenı´ dat. Informace o stazˇeny´ch stra´nka´ch proto ulozˇ´ıme do dvou tabulek Page a URL se vza´jemny´m vztahem 1:N (viz obra´zek 6.1). Page
[1:N]
URL
Obra´zek 6.1: ER-diagram databa´ze pro ukla´da´nı´ stra´nek
Na´zev atributu id md5
Typ int, automaticky zveˇtsˇovany´ char(32)
md5dia
char(32)
type
varchar(128)
data modified
longvarchar/clob timestamp
Popis Identifika´tor stra´nky, slouzˇ´ı jako umeˇly´ prima´rnı´ klı´cˇ tabulky Vy´tah zpra´vy pouzˇ´ıvany´ prˇi kontrole zmeˇny obsahu stra´nky a hleda´nı´ kopiı´ jedne´ stra´nky Vy´tah zpra´vy bez diakritiky pouzˇ´ıvany´ prˇi kontrole zmeˇny obsahu stra´nky a hleda´nı´ kopiı´ jedne´ stra´nky MIME typ stra´nky (naprˇ. text/html, text/plain) Samotny´ obsah stra´nky Datum a cˇas poslednı´ modifikace za´znamu tj. stra´nky
Tabulka 6.1: Struktura tabulky Page
3
Do te´to skupiny patrˇ´ı i verze stra´nky v ru˚zny´ch ko´dova´nı´ch, ktere´ jsou dostupne´ na drobneˇ odlisˇny´ch URL adresa´ch.
55
6.2. NA´VRH POSTUPU PRO STAHOVA´NI´ A UKLA´DA´NI´ STRA´NEK Na´zev atributu url page id
Typ varchar(1024) int
fetched checked expires status
datetime datetime datetime int
Popis URL zdroje, prima´rnı´ klı´cˇ tabulky Identifika´tor stra´nky, kterou dane´ URL obsahuje Datum a cˇas prvnı´ho stazˇenı´ URL Datum a cˇas poslednı´ kontroly URL Datum a cˇas vyprsˇenı´ platnosti zdroje Poslednı´ HTTP stavovy´ ko´d zı´skany´ prˇi cˇtenı´ URL
Tabulka 6.2: Struktura tabulky URL
Neˇktere´ moduly mohou potrˇebovat i informaci o odkazech mezi dokumenty. Struktura odkazu˚ nenı´ nic jine´ho nezˇ orientovany´ graf. Ten lze v relacˇnı´m modelu zachytit naprˇ´ıklad jako seznam usporˇa´dany´ch dvojic zdrojove´ho a cı´love´ho uzlu. Na´zev atributu source target
Typ int int
Popis Identifika´tor zdrojove´ stra´nky Identifika´tor cı´love´ stra´nky
Tabulka 6.3: Struktura tabulky Link pro ukla´da´nı´ odkazu˚ mezi stra´nkami Prima´rnı´ klı´cˇ je v tabulce Link prˇitom tvorˇen obeˇma dveˇma atributy. Tato struktura umozˇnˇuje velice jednodusˇe zjistit prˇ´ıme´ho prˇedka a na´slednı´ka kazˇde´ stra´nky. Pro hleda´nı´ neprˇ´ımy´ch vazeb (prˇes vı´ce stra´nek) vsˇak jazyk SQL, ktery´ se pouzˇ´ıva´ pro dotazova´nı´ v tabulka´ch, nenabı´zı´ vhodne´ prostrˇedky.
6.2
Na´vrh postupu pro stahova´nı´ a ukla´da´nı´ stra´nek
Modul pro stahova´nı´ stra´nek bude slouzˇit k naplneˇnı´ a u´drzˇbeˇ vy´sˇe popsane´ databa´ze stra´nek. V na´sledujı´cı´m textu se pokusı´m popsat, jak by meˇl modul pro stahova´nı´ stra´nek pracovat a jake´ dalsˇ´ı pomocne´ datove´ struktury budeme potrˇebovat. URL stra´nek, jezˇ potrˇebujeme sta´hnout, budeme pru˚beˇzˇneˇ ukla´dat do fronty, ze ktere´ budou postupneˇ cˇtena. Stahnutı´ a zpracova´nı´ stra´nky by meˇlo probı´hat zhruba podle na´sledujı´cı´ho sce´na´rˇe: 1. Stazˇenı´ stra´nky z dane´ho URL. Pokud je stra´nka nedostupna´, zapı´sˇe se do tabulky URL chybovy´ ko´d a stahova´nı´ se ukoncˇ´ı. 2. Normalizace ko´dova´nı´ stra´nek. Pro dalsˇ´ı zpracova´nı´ je nezbytneˇ nutne´ sjednotit ko´dova´nı´ cˇesˇtiny pouzˇ´ıvane´ na stra´nka´ch. Pro nasˇe potrˇeby bude asi nejvhodneˇjsˇ´ı vsˇechny stra´nky prˇeve´st do ko´dova´nı´ ISO 8859-2, nebo UTF-8. Detekce ko´dova´nı´ nenı´ zcela trivia´lnı´ za´lezˇitost, ale mu˚zˇeme se inspirovat naprˇ´ıklad zdrojovy´mi ko´dy vyhleda´vacˇe Sherlock [29], ktery´ tento proble´m pomeˇrneˇ uspokojiveˇ rˇesˇ´ı. 3. Kanonizace do XML. Prˇeva´zˇna´ veˇtsˇina dnesˇnı´ch HTML stra´nek obsahuje mnoho syntakticky´ch chyb a znemozˇnˇuje jejich snadne´ zpracova´nı´ pomocı´ jednoduche´ho parseru. 56
6.2. NA´VRH POSTUPU PRO STAHOVA´NI´ A UKLA´DA´NI´ STRA´NEK Prˇi nacˇ´ıta´nı´ proto vsˇechny stra´nky prˇevedeme do XML, a tı´m usnadnı´me jejich zpracova´nı´ dalsˇ´ım aplikacı´m.Tento krok se vyplatı´ i s ohledem na budoucnost. Dalsˇ´ı verze HTML – XHTML – ma´ jizˇ prˇ´ımo syntaxi XML, na Webu se postupneˇ objevı´ informace dostupne´ pouze v XML. 4. Testova´nı´ zmeˇny stra´nky a opakovane´ho vy´skytu. V tomto kroku zjistı´me, zda se nacˇtena´ stra´nka jizˇ v databa´zi nevyskytuje pod jiny´m URL, nebo zda nedosˇlo ke zmeˇneˇ stra´nky od jejı´ho poslednı´ho zarˇazenı´ do databa´ze. 5. Aktualizace databa´ze. V za´vislosti na prˇedchozı´m kroku jsou prˇ´ıslusˇne´ tabulky v databa´zi modifikova´ny – bud’ je prˇida´na nova´ stra´nka, nebo jsou upraveny u´daje o sta´vajı´cı´ch stra´nka´ch a URL. 6. Aktualizace fronty dokumentu˚ ke stazˇenı´. Ze zpracovane´ho dokumentu zı´ska´me vsˇechny odkazy. Ty, ktere´ jesˇteˇ nema´me ulozˇene´ v tabulce URL nebo ve fronteˇ, prˇida´me do fronty URL adres ke zpracova´nı´.
6.2.1 Stahova´nı´ stra´nek z dane´ho URL Samotne´ stazˇenı´ stra´nky z dane´ URL adresy nenı´ prˇ´ılisˇ slozˇite´, protozˇe mnoho programovacı´ch jazyku˚ jizˇ prˇ´ımo obsahuje funkce, ktere´ toto umozˇnˇujı´. Pokud vsˇak stahujeme veˇtsˇ´ı mnozˇstvı´ stra´nek z vı´ce serveru˚, musı´me zva´zˇit i dalsˇ´ı okolnosti. Existuje vsˇeobecneˇ akceptovany´ standard [36], ktery´m mu˚zˇe spra´vce webove´ho serveru zaka´zat stahova´nı´ stra´nek pro automaticky pracujı´cı´ roboty. Informace o stra´nka´ch, ktere´ by se nemeˇly stahovat, se ukla´dajı´ do souboru robots.txt v korˇenove´m adresa´rˇi webove´ho serveru. Pro nasˇe potrˇeby bychom si meˇli pro kazˇdy´ server (dome´nove´ jme´no + port) pamatovat obsah tohoto souboru a prˇi stahova´nı´ se jı´m rˇ´ıdit. Za´kaz indexova´nı´ a zpracova´nı´ dalsˇ´ıch odkazu˚ lze uve´st i prˇ´ımo v za´hlavı´ dokumentu. Na´sˇ robot by meˇl respektovat i toto nastavenı´ v hlavicˇce stra´nky: <META name=”ROBOTS” content=”NOINDEX, NOFOLLOW”> Pro efektivnı´ stahova´nı´ by bylo vy´hodne´ stahovat stra´nky paralelneˇ z neˇkolika serveru˚ najednou. Aby nedocha´zelo k prˇeteˇzˇova´nı´ serveru˚, nemeˇlo by probı´hat stahova´nı´ vı´ce souboru˚ z jednoho serveru za´rovenˇ. Fronta URL ke stazˇenı´ proto bude muset fungovat jako neˇkolik samostatny´ch front pro jednotlive´ servery. Z nasˇeho u´hlu pohledu budeme jako webovy´ server cha´pat dvojici jeho dome´nove´ho jme´na (prˇ´ıpadneˇ IP adresy, pokud dome´nove´ jme´no nebude k dispozici) a portu. Pro kazˇdy´ webovy´ server si budeme pamatovat informace zı´skane´ z robots.txt a stavovy´ ko´d poslednı´ operace. Pokud bude vy´sledkem poslednı´ operace na serveru chyba, ktera´ znamena´ nefunkcˇnost serveru, budeme muset na neˇjaky´ cˇas prˇerusˇit stahova´nı´ ze serveru.
6.2.2
Normalizace ko´dova´nı´
Jazyk HTML pouzˇ´ıva´ jako znakovou sadu Unicode [35], [41]. Pro za´pis unicodovy´ch znaku˚ vsˇak mohou ru˚zne´ stra´nky pouzˇ´ıvat ru˚zna´ ko´dova´nı´. Pro cˇesˇtinu se nejcˇasteˇji pouzˇ´ıvajı´ ko´dova´nı´ windows-1250, iso-8859-2 a utf-8. Mnoho stra´nek je z historicky´ch du˚vodu˚ prˇ´ıstupny´ch pomocı´ ru˚zny´ch modulu˚ pro dynamickou zmeˇnu ko´dova´nı´ i v neˇkolika dalsˇ´ıch ko´dova´nı´ch – naprˇ. Mac CE, CP852, ko´dova´nı´ bratrˇ´ı Kamenicky´ch apod. 57
6.2. NA´VRH POSTUPU PRO STAHOVA´NI´ A UKLA´DA´NI´ STRA´NEK Spra´vne´ rozpozna´nı´ ko´dova´nı´ je klı´cˇove´ pro namapova´nı´ zı´skane´ sekvence bajtu˚ na unicodovy´ textovy´ rˇeteˇzec. Ten pak mu˚zˇe poslouzˇit jako vstup pro dalsˇ´ı moduly. Specifikace HTML [35] v cˇa´sti 5.2 popisuje, jaky´m zpu˚sobem se ma´ zjisˇt’ovat ko´dova´nı´ dokumentu. Nejvysˇsˇ´ı prioritu ma´ obsah hlavicˇky Content-type z HTTP odpoveˇdi. Ten mu˚zˇe obsahovat naprˇ.: Content-type: text/html;charset=iso-8859-2 Hlavicˇka rˇ´ıka´, zˇe se jedna´ o HTML dokument (MIME typ text/html) a zˇe je v ko´dova´nı´ iso-8859-2. Pokud nenı´ ko´dova´nı´ urcˇeno v HTTP hlavicˇka´ch, hleda´ se odpovı´dajı´cı´ meta tag v prˇ´ımo v HTML dokumentu. <meta http-equiv=”Content-type” content=”text/html;charset=iso-8859-2”> Jediny´ proble´m je v tom, zˇe neˇktere´ stra´nky neobsahujı´ ani meta tag, ani se informace o ko´dova´nı´ neposı´la´ v hlavicˇka´ch. V tomto prˇ´ıpadeˇ musı´me ko´dova´nı´ uhodnout. Jednak mu˚zˇeme pouzˇ´ıt analy´zu cˇetnosti vy´skytu jednotlivy´ch znaku˚, ktera´ se pro ru˚zna´ ko´dova´nı´ samozrˇejmeˇ lisˇ´ı. Pro stra´nky v cˇesˇtineˇ navı´c platı´, zˇe nejcˇasteˇji by´vajı´ pra´veˇ v ko´dova´nı´ windows-1250.
6.2.3 Kanonizace do XML Pro prˇevod HTML stra´nek do XML mu˚zˇeme pouzˇ´ıt program HTML-Tidy [34]. Ten kromeˇ prˇevodu do XML odstranı´ mnoho chyb, ktere´ se dnes v HTML ko´du vyskytujı´. Prˇevod XML a XHTML4 do XML nenı´ vu˚bec nutny´. Dokument zkra´tka jen ulozˇ´ıme do databa´ze. Prˇevod textovy´ch dokumentu˚ do XML je velice jednoduchy´. Mu˚zˇeme se pokusit vytvorˇit heuristiky, ktere´ budou hledat naprˇ´ıklad jednotlive´ odstavce textu a uzavrˇou je do neˇjake´ho elementu. Prˇevod SGML dokumentu˚ take´ nebude nikterak obtı´zˇny´. Pokud SGML dokument znormalizujeme,5 dostaneme forma´t, z neˇhozˇ lze XML vyrobit velice jednodusˇe. Dalsˇ´ımi slozˇiteˇjsˇ´ımi forma´ty, jako je PDF nebo DOC, se zatı´m zaby´vat nebudeme. Nicme´neˇ je vhodne´ prˇevod do XML napsat modula´rneˇ tak, aby sˇla v budoucnu snadno prˇidat podpora pro dalsˇ´ı vstupnı´ forma´ty.
6.2.4
Testova´nı´ zmeˇny a opakovane´ho vy´skytu
Pokud budeme chtı´t neˇjaky´m efektivnı´m zpu˚sobem zjistit, zda pra´veˇ zı´skana´ stra´nka jizˇ nenı´ v nasˇ´ı databa´zi pod jiny´m URL, s vy´hodou vyuzˇijeme vlastnosti algoritmu MD5 nebo obdobne´ho „message digest“ algoritmu. Funkce MD5 prˇirˇazuje kazˇde´mu textu 128bitove´ cˇ´ıslo. Z vlastnostı´ algoritmu vyply´va´, zˇe pokud jsou dva texty ru˚zne´, je pravdeˇpodobnost, zˇe budou mı´t stejnou hodnotu MD5, velmi mala´. 4
XHTML je verze HTML zapisovana´ striktneˇ v XML syntaxi. Normalizacı´ SGML dokumentu se oznacˇuje proces, kdy se do instance dokumentu doplnı´ vsˇechno znacˇkova´nı´, ktere´ mohlo by´t dı´ky specia´lnı´m minimalizacˇnı´m pravidlu˚m definovany´m v SGML, v SGML deklaraci nebo v DTD vynecha´no. 5
58
6.3. IMPLEMENTACE STAHOVA´NI´ STRA´NEK Pro stra´nku proto spocˇ´ıta´me MD5 a snadno tak zjistı´me, zda jizˇ stejnou stra´nku nema´me zaindexovanou – meˇla by stejne´ MD5. Pro jistotou mu˚zˇeme jesˇteˇ stra´nky se stejny´m MD5 klasicky porovnat. Neˇktere´ stra´nky jsou na webu dostupne´ v neˇkolika ru˚zny´ch ko´dova´nı´ch vcˇetneˇ us-ascii – bez diakritiky. U kazˇde´ stra´nky bychom proto take´ meˇli spocˇ´ıtat MD5 jejı´ho textu po odstraneˇnı´ diakritiky. Jen tak mu˚zˇeme dostatecˇneˇ du˚kladneˇ detekovat duplicitnı´ stra´nky. Prˇi ukla´da´nı´ da´va´me samozrˇejmeˇ prˇednost stra´nce s diakritikou prˇed stra´nkou bez diakritiky – ocenı´ to zejme´na lingvisticke´ moduly. Kromeˇ hleda´nı´ duplicitnı´ch stra´nek na´m MD5 umozˇnı´ snadno zjistit, zda se stra´nka s dany´m URL od poslednı´ho stazˇenı´ nezmeˇnila. Prˇi zmeˇneˇ obsahu stra´nky se samozrˇejmeˇ zmeˇnı´ i jejı´ MD5.
6.3
Implementace stahova´nı´ stra´nek
V prˇedchozı´m textu jsme dosˇli k za´veˇru, zˇe pro nasˇe potrˇeby bude nejvhodneˇjsˇ´ı implementovat vlastnı´ program pro stahova´nı´ a ukla´da´nı´ stra´nek. V na´sledujı´cı´m textu se proto zameˇrˇ´ım na neˇktere´ zajı´maveˇjsˇ´ı aspekty implementace robota.
6.3.1 Vy´beˇr implementacˇnı´ho prostrˇedı´ Abychom mohli vybrat implementacˇnı´ prostrˇedı´, musı´me si nejprve stanovit pozˇadavky. Pro implementaci syste´mu potrˇebujeme jazyk, ktery´: • podporuje HTTP protokol, ktery´m budeme stahovat stra´nky; • umozˇnˇuje pra´ci s XML dokumenty; • podporuje vı´cevla´knove´ aplikace pro paralelnı´ stahova´nı´ stra´nek z neˇkolika serveru˚ najednou; • umozˇnˇuje prˇ´ıstup do databa´ze; • autor ho alesponˇ trochu ovla´da´. Tato krite´ria (s vy´jimkou poslednı´ho) na´m vy´beˇr prˇ´ılisˇ neusnadnı´, protozˇe jim vyhovı´ kazˇdy´ beˇzˇneˇ pouzˇ´ıvany´ jazyk. Rozhodl jsem se proto pouzˇ´ıt Javu, ktera´ obsahuje bohate´ knihovny a navı´c je neza´visla´ na platformeˇ – vy´slednou prototypovou aplikaci si bude moci vyzkousˇet kazˇdy´ neza´visle´ na pouzˇite´ platformeˇ.
6.3.2 Architektura modulu pro stahova´nı´ stra´nek Cely´ stahovacı´ modul je pomeˇrneˇ jednoduchy´. Hlavnı´ program po spusˇteˇnı´ nacˇte konfiguraci, ktera´ nastavuje du˚lezˇite´ parametry – stra´nku, kterou se ma´ zaha´jit stahova´nı´, z kolika serveru˚ se majı´ stra´nky stahovat najednou atd. Pote´ se spustı´ neˇkolik vla´ken a kazˇde´ stahuje stra´nky z jednoho serveru. Prˇed samotny´m stazˇenı´m je testova´no, zda adresa stra´nky vyhovuje regula´rnı´m vy´razu˚m, ktere´ definujı´ filtr pro stra´nky, jezˇ na´s zajı´majı´. Po stazˇenı´ stra´nky se na za´kladeˇ jejı´ho typu rozhodne, jak bude zpracova´na. Zatı´m je implementova´na jen trˇ´ıda pro obsluhu HTML ko´du. Ta vyuzˇ´ıva´ knihovnu JTidy,6 ktera´ umı´ 6
http://sourceforge.net/projects/jtidy
59
6.3. IMPLEMENTACE STAHOVA´NI´ STRA´NEK opravit syntakticke´ chyby v HTML ko´du (jedna´ se o javovou verzi programu HTML-Tidy) a vy´sledek pak nabı´zı´ pomocı´ DOM rozhranı´. Pomocı´ DOM parseru se projde cely´ dokument a zı´skajı´ se z neˇj vsˇechny odkazy, ktere´ se vlozˇ´ı do fronty. Stra´nka je pak prˇevedena do textove´ podoby XML dokumentu, spocˇ´ıtajı´ se jejı´ vy´tahy (MD5) s diakritikou i bez nı´ a stra´nka se ulozˇ´ı do databa´ze stazˇeny´ch stra´nek (prˇedtı´m se samozrˇejmeˇ testuje, zda jizˇ v databa´zi neexistuje stejna´ stra´nka s jinou URL adresou). Takto stazˇene´ stra´nky jsou pak ostatnı´m modulu˚m k dispozici pomocı´ sluzˇby, ktera´ pouzˇ´ıva´ webove´ rozhranı´. Jejı´ rozhranı´ definovane´ pomocı´ WSDL naleznete v prˇ´ıloze A – Modul pro stahova´nı´ stra´nek. Samotne´ zdrojove´ ko´dy modulu pro stahova´nı´ nejsou nijak zajı´mave´, prˇ´ıpadnı´ za´jemci si je mohou vyzˇa´dat prˇ´ımo od autora.
60
Kapitola 7 Za´veˇr Cı´lem diplomove´ pra´ce bylo navrhnout a vytvorˇit na´stroj, ktery´ by usnadnil navigaci po webovy´ch stra´nka´ch. Navrzˇene´ rˇesˇenı´ spocˇ´ıva´ ve vytvorˇenı´ specia´lnı´ho navigacˇnı´ho panelu pro prohlı´zˇecˇ. V tomto panelu se pak zobrazujı´ prˇ´ıdavne´ informace o stra´nce, jako podobne´ stra´nky, metadata apod. Vy´sledkem pra´ce je funkcˇnı´ navigacˇnı´ rozhranı´, ktere´ integruje vy´sledky z neˇkolika modulu˚ dostupny´ch pomocı´ protokolu SOAP. Ma´ pra´ce oveˇrˇila, zˇe distribuovana´ architektura vyuzˇ´ıvajı´cı´ protokol SOAP je pouzˇitelna´. Kromeˇ navigacˇnı´ho modulu vznikl i modul pro stahova´nı´ stra´nek. Pro dalsˇ´ı rozvoj cele´ho syste´mu RAINBOW je klı´cˇove´ prˇedevsˇ´ım vytvorˇenı´ a integrova´nı´ dalsˇ´ıch analyticky´ch modulu˚.
61
Literatura [1] Berka, P. – Sochorova´, M. – Sva´tek, V. – Sˇra´mek, D.: The VSEved System for Intelligent WWW Metasearch. In: Rudas, I. – Madarasz, L.: INES’99 – IEEE Intl. Conf. on Intelligent Engineering Systems. 1999. [2] Boag, S. – Chamberlin, D. – Fernandez, M. – Florescu, D. – Robie, J. – Sime´on, J. – Stefanescu, M.: XQuery 1.0: An XML Query Language. W3C Working Draft. 2002. URL: http://www.w3.org/TR/xquery/ [3] Box, D.: A Brief History of SOAP. O’Reilly XML.com. URL: http://www.xml.com/pub/a/2001/04/04/soap.html [4] Box, D. – Ehnebuske, D. – Kakivaya, G. – Layman, A. – Mendelsohn, N. – Nielsen, H. – Thatte, S. – Winer, D.: Simple Object Access Protocol (SOAP) 1.1. W3C Note. 2000. URL: http://www.w3.org/TR/SOAP/ [5] Bradley, N.: The XML companion. Addison Wesley Longman Limited, 1998. ISBN 0-201-34285-5. [6] Bray, T. – Paoli, J. – Sperberg-McQueen, C. – Maler, E.: Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation. 2000. URL: http://www.w3.org/TR/REC-xml [7] Bray, T. – Hollander, D. – Layman, A.: Namespaces in XML. W3C, 1999. URL: http://www.w3.org/TR/REC-xml-names/ [8] Clark, J. – Makoto, M.: RELAX NG Specification. OASIS, 2001. URL: http: //www.oasis-open.org/committees/relax-ng/spec-20011203.html [9] Clark, J.: XSL Transformations (XSLT) Version 1.0. W3C Recommendation. 1999. URL: http://www.w3.org/TR/xslt [10] Cowan, J. – Tobin, R.: XML Information Set. W3C Recommendation. 2001. URL: http://www.w3.org/TR/xml-infoset/ [11] DeRose, S. – Maler, E. – Orchard, D.: XML Linking Language (XLink) Version 1.0. W3C Recommendation. 2001. URL: http://www.w3.org/TR/xlink/ [12] DeRose, S. – Maler, E. – Daniel, R.: XML Pointer Language (XPointer) Version 1.0. W3C Candidate Recommendation. 2001. URL: http://www.w3.org/TR/xptr/ [13] Dubinko, M. – Dietl, J. – Klotz, L. – Merrick, R. – Raman, T.: XForms 1.0. W3C Working Draft. 2002. URL: http://www.w3.org/TR/xforms/ 62
LITERATURA [14] Fallside, D.: XML Schema Part 0: Primer. W3C Recommendation. 2001. URL: http://www.w3.org/TR/xmlschema-0/ [15] Ferraiolo, J.: Scalable Vector Graphics (SVG) 1.0 Specification. W3C Recommendation. 2001. URL: http://www.w3.org/TR/SVG/ [16] Fielding, R. – Gettys, J. – Mogul, J. – Frystyk, H. – Masinter, L. – Leach, P. – Berners-Lee, T.: RFC2616: Hypertext Transfer Protocol – HTTP/1.1. IETF, 1999. URL: http://www.ietf.org/rfc/rfc2616.txt [17] Gudgin, M. – Hadley, M. – Moreau, J. – Nielsen, H.: SOAP Version 1.2 Part 1: Messaging Framework. W3C Working Draft. 2001. URL: http://www.w3.org/TR/soap12-part1/ [18] Holman, G.: CD 19757-0 – DSDL Part 0 – Overview. Document Schema Definition Language. ISO/IEC JTC 1/SC34, 2001. URL: http://www.jtc1.org/FTP/Public/SC34/DOCREG/0275.htm [19] Le Hors, A. – Le He´garet, P. – Wood, L.: Document Object Model (DOM) Level 2 Core Specification. W3C Recommendation. 2000. URL: http://www.w3.org/TR/DOM-Level-2-Core [20] Hyatt, D.: XBL – XML Binding Language. W3C Note. 2001. URL: http://www.w3.org/TR/xbl/ [21] Hyatt, D.: XML User Interface Language (XUL) 1.0. URL: http://www.mozilla.org/projects/xul/xul.html [22] Christensen, E. – Curbera, F. – Meredith, G. – Weerawarana, S.: Web Services Description Language (WSDL) 1.1. W3C Note. 2001. URL: http://www.w3.org/TR/wsdl [23] ISO (International Organization for Standardization): ISO 8879:1986(E). Information processing – Text and Office Systems – Standard Generalized Markup Language (SGML). 1986. [24] Kosek, J.: XML pro kazˇde´ho. Grada Publishing, Praha 2000. ISBN 80-7169-860-1. Str. 164. [25] Kosek, J. – Sva´tek, V.: XML a ontologie jako integracˇnı´ na´stroje pro analy´zu a zprˇ´ıstupnˇova´nı´ WWW. Str. 183-192. In: Valenta, J.: Datasem 2000 Proceedings. 2000. ISBN 80-210-2428-3. [26] Kosek, J.: XUL. Str. 88-91. In: Softwarove´ noviny. 8/2001. ISSN 1210-8472. [27] Lassila, O. – Swick, R.: Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation. 1999. URL: http://www.w3.org/TR/REC-rdf-syntax/ [28] Lawrence, S. – Giles, L.: Accessibility and Distribution of Information on the Web. URL: http://wwwmetrics.com/ [29] Maresˇ, M.: Sherlock – A Network Document Space Search System. URL: ftp://atrey.karlin.mff.cuni.cz/pub/local/mj/sherlock/ papers/sherlock-1.0.ps.gz
63
LITERATURA [30] McCaron, S. – Pemberton, S. – Raman, T.: XML Events. W3C Working Draft. 2001. URL: http://www.w3.org/TR/xml-events/ [31] Megginson, D.: SAX 2.0. URL: http://www.saxproject.org/ [32] Nielsen, H. – Leach, P. – Lawrence, S.: RFC 2774: An HTTP Extension Framework. IETF, 2000. URL: http://www.ietf.org/rfc/rfc2774.txt [33] Pokorny´, J.: Databa´ze a Web. Str. 4-22. In: Modernı´ databa´ze 2001. URL: http://www.komix.cz/napsal/md2001/md_mffuk.zip [34] Raggett, D.: Clean up your Web pages with HTML TIDY. URL: http://www.w3.org/People/Raggett/tidy/ [35] Raggett, D. – Le Hors, A. – Jacobs, I.: HTML 4.01 Specification. W3C Recommendation. 1999. URL: http://www.w3.org/TR/html401/ [36] A Standard for Robot Exclusion. URL: http: //info.webcrawler.com/mak/projects/robots/norobots.html [37] Sˇimek, P.: Ontologie a WWW. Diplomova´ pra´ce. Praha, VSˇE, 1999. [38] Sˇtumpf, J.: Syste´my rˇ´ızenı´ vy´meˇny zpra´v a XML (XML Messaging). Str. 67-98. In: Bielikova´, M.: Datakon 2001 Proceedings. 2001. ISBN 80-227-1597-2. [39] Systinet: Vy´voj Web Services. Prakticke´ uka´zky technologiı´ SOAP, WSDL a UDDI. 2001. [40] Thai, T. – Lam, H.: .NET Framework Essentials. O’Reilly, 2001. ISBN 0-596-00165-7. [41] The Unicode Consortium: The Unicode Standard. Version 3.0. Addison-Wesley, 2000. ISBN 0-201-61633-5. [42] Uschold, M. – Gruninger, M.: Ontologies: principles, methods and applications. Str. 93-136. In: The Knowledge Engineering Review. 1996. Vol. 11:2. [43] w3mir’s homepage. URL: http://www.math.uio.no/˜janl/w3mir/ [44] Wget. URL: http://www.gnu.org/software/wget/wget.html
Aby meˇl navigacˇnı´ modul prˇ´ıstup k hlavnı´mu oknu prohlı´zˇecˇe, ze ktere´ho zjisˇt’uje informace o pra´veˇ nacˇtene´ stra´nce, musı´me navigacˇnı´ panel nainstalovat pomocı´ instalacˇnı´ technologie XPInstall. Kvu˚li chybeˇ v Mozille je instalace trochu krkolomna´, nicme´neˇ funkcˇnı´. Postup je na´sledujı´cı´: 1. Nainstalujte si prohlı´zˇecˇ Mozilla z adresy http://www.mozilla.org. Rozhranı´ bylo testova´no s verzı´ 0.9.9. Verze 1.0 RC1 obsahuje chybu, kvu˚li ktere´ navigacˇnı´ panel nefunguje. Cˇisteˇ teoreticky by meˇlo vsˇe fungovat s libovolnou verzı´ Mozilly, ale prakticky je to odzkousˇene´ jen s verzı´ 0.9.9. 2. V Mozille si otevrˇete adresu http://rainbow.vse.cz:8000/rainbow/rainbow. xpi. Prohlı´zˇecˇ se zepta´, zda mu˚zˇe instalovat software. Po potvrzenı´ a instalaci restartujte Mozillu. 3. Vyberte prˇ´ıkaz z menu Tasks → RAINBOW Add Panel. Opeˇt restartujte Mozillu. 4. V postranı´m pruhu by meˇl by´t videˇt dalsˇ´ı panel – RAINBOW. Funguje zcela automaticky, stacˇ´ı zcela klasicky brouzdat po stra´nka´ch a do neˇkolika sekund po nacˇtenı´ nove´ stra´nky by se meˇly objevit i informace o stra´nce v panelu. Prˇ´ıklad B.11: Navigacˇnı´ panel pro Mozillu <window xmlns= ”http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul”> <script type=”application/x-javascript”> // base URL of xulservlet var baseUrl = ”http://rainbow.vse.cz:8000/rainbow/xulservlet?url=” // old URL 67
B.2. SERVLET SLOUZˇI´CI´ JAKO DOTAZOVACI´ MODUL
var oldUrl = ””; var newUrl = ”” // reload results when displayed page is changed function update() { newUrl = window._content.location; if (newUrl != oldUrl) { oldUrl = ”” + newUrl; // make copy, not reference document.getElementById(’results’). setAttribute(’src’, baseUrl + newUrl); } } var timer = window.setInterval(”update()”, 1000); <iframe id=”results” src=”about:blank” flex=”1” />
B.2 Servlet slouzˇı´cı´ jako dotazovacı´ modul Servlet je specia´lnı´ trˇ´ıda v jazyce Java, ktera´ beˇzˇ´ı v ra´mci servletove´ kontejneru. To je specia´lnı´ web server, ktery´ je schopny´ hostovat pra´veˇ servlety. Funkcˇnı´ verze servletu je dostupna´ na adrese http://rainbow.vse.cz:8000/rainbow/xulservlet. Prˇ´ıklad B.12: Servlet generujı´cı´ XUL ko´d package cz.vse.rainbow.servlets; // standard and servlet imports import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; // WS imports import client.iface.*; import client.iface.struct.*; import org.idoox.wasp.Context; import org.idoox.wasp.MessageAttachment; import org.idoox.webservice.client.WebService; import org.idoox.webservice.client.WebServiceLookup; 68
B.2. SERVLET SLOUZˇI´CI´ JAKO DOTAZOVACI´ MODUL
import org.idoox.webservice.client.WebServiceLookupException; // servlet which returns information about specific URL // as XUL document // URL should be passed by GET method in ”url” parameter public class XULServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException { // generate begin of XUL page response.setContentType( ”application/vnd.mozilla.xul+xml; charset=utf-8”); PrintWriter out = response.getWriter(); out.println(”\n” + ”\n” + ”<window xmlns=’http://www.mozilla.org/keymaster/ gatekeeper/there.is.only.xul’>\n” + ”<script type=’application/x-javascript’>\n” + ”function openTopWin( url )\n” + ”{ window._content.location = url; }\n” + ”\n” + ”\n” + ” \n” + ” \n” + ” \n” + ” \n” + ” \n”); String googleHost = ”http://api.google.com/search/beta2”; String metadataHost = ”http://rainbow.vse.cz:8000/wasp/Metadata/”; String lingHost = ”http://rainbow.vse.cz:7878”; try { //init the lookup WebServiceLookup lookup = (WebServiceLookup)Context.getInstance (”org.idoox.webservice.client.WebServiceLookup”); // ask Google for related pages GoogleSearchPort serviceGoogle = (GoogleSearchPort)lookup. lookup(”http://api.google.com/GoogleSearch.wsdl”, GoogleSearchPort.class,googleHost); GoogleSearchResult r = serviceGoogle.doGoogleSearch 69
B.2. SERVLET SLOUZˇI´CI´ JAKO DOTAZOVACI´ MODUL
(”...heslo pro pr ˇ´ ıstup ke sluz ˇbe ˇ...”, ”related:” + request.getParameter(”url”), 0, 10, false, ””, false, ””, ””, ””); out.println(”\n” + ”\n” + ”\n” + ”\n” + ”\n”); for (int i=0; i < r.resultElements.length; i++) { String title = escapeXML(r.resultElements[i].title); String url = escapeXML(r.resultElements[i].URL); if (title.equals(””)) title = url; out.println(”\n” + ”\n” + ”\n”); } if (r.resultElements.length == 0) { out.println(”\n” + ”\n” + ”\n”); } out.println(”\n”); // ask Metadata service for metadata Metadata serviceMetadata = (Metadata)lookup. lookup(”http://rainbow.vse.cz:8000/wasp/Metadata/”, Metadata.class,metadataHost); Metalist listtags = new Metalist(); MetalistHolder objmeta = new MetalistHolder(); objmeta.setValue(listtags); serviceMetadata.getTags(request.getParameter(”url”), objmeta); listtags = objmeta.getValue(); out.println(”\n” + ”\n” + ”\n” + ”\n” + 70
