Webové služby aplikace FAKE GAME

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Bakalářská práce

Webové služby aplikace FAKE GAME Vladimír Šťastný

Vedoucí práce: Ing. Pavel Kordík, Ph.D.

Studijní program: Softwarové technologie a management, kombinované Obor: Softwarové inženýrství červen 2009

iv

v

Poděkování Chtěl bych poděkovat panu Ing. Pavlu Kordíkovi, Ph.D. za jeho trpělivost a zodpovídaní všech mých dotazů.

vi

vii

Prohlášení Prohlašuji, že jsem svou bakalářskou práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon). V Praze dne 29. června 2009

…...... .

viii

ix

Abstract At first, this bachelor thesis deals with the web services in the complex view. It focuses on the main principles which are essential for the web services. Also, the existing concept of web services based on the grid technology is described. Then, the thesis is concerned with the FAKE GAME application. The main effort is to introduce the FAKE GAME application so that it could be used in the practical part of the thesis. At the end, a possible concept of web services relating to the FAKE GAME application is described.

Abstrakt Tato práce se nejprve zabývá webovými službami v obecné rovině. Všímá si základních principů, na nichž jsou webové služby postaveny. Poté je představena existující koncepce webových služeb založená na využití grid technologie. Následně je věnována pozornost aplikaci FAKE GAME. Snahou je aplikaci představit alespoň v takové rovině, která umožní použití FAKE GAME v praktické části této práce. V závěrečné části je popsáno vlastní řešení webových služeb pro aplikaci FAKE GAME.

x

xi

Obsah 1 Úvod....................................................................................................................................1 2 Webové služby....................................................................................................................2 2.1 Technologie využívané webovými službami...................................................................2 2.1.1 SOAP protokol.........................................................................................................2 2.1.2 WSDL.......................................................................................................................3 2.1.3 UDDI a WSIL...........................................................................................................4 2.2 JAX-WS...........................................................................................................................4 2.2.1 SOAP protokol.........................................................................................................4 2.2.2 Anotace.....................................................................................................................6 2.2.3 Realizace...................................................................................................................6 2.3 Webové služby ve spojení s data miningem....................................................................7 3 Příklad webových služeb pro data mining..........................................................................8 3.1 Weka4WS.........................................................................................................................8 3.1.1 Úvod.........................................................................................................................8 3.1.2 Globus Toolkit 4.0.x (GT4)......................................................................................8 3.1.3 Weka4WS framework............................................................................................11 4 Aplikace FAKE GAME....................................................................................................15 4.1 Úvod...............................................................................................................................15 4.2 Programové rozhraní FAKE GAME..............................................................................16 5 Vlastní řešení webových služeb........................................................................................17 5.1 Řešení s příkazovým řádkem.........................................................................................17 5.1.1 Popis.......................................................................................................................17 5.1.2 Implementace..........................................................................................................19 5.2 Řešení s využitím zdrojového kódu...............................................................................20 5.2.1 Popis.......................................................................................................................20 5.2.2 Implementace..........................................................................................................22 6 Testování...........................................................................................................................24 7 Závěr..................................................................................................................................25 7.1 Možná vylepšení a rozšíření...........................................................................................25 8 Literatura...........................................................................................................................26 A Uživatelská / instalační příručka......................................................................................27 Instalace............................................................................................................................27 Návod k uživatelskému ovládání programu.....................................................................27 Řešení 1........................................................................................................................27 Řešení 2........................................................................................................................27 B Obsah přiloženého CD......................................................................................................28 C Webové služby na školním serveru..................................................................................29

xii

xiii

Seznam obrázků Obr. 1: Komunikace webové služby......................................................................................5 Obr. 2: Vazby mezi komponentami GT4...............................................................................9 Obr. 3: GT4 architektura......................................................................................................10 Obr. 4: Architektura Weka4WS...........................................................................................12 Obr. 5: Explorer panel Weka4WS........................................................................................13 Obr. 6: Hlavní okno aplikace FAKE GAME.......................................................................16 Obr. 7: Okno klienta webové služby....................................................................................18 Obr. 8: Use Case diagram.....................................................................................................19 Obr. 9: Class diagram...........................................................................................................20 Obr. 10: Use Case diagram...................................................................................................21 Obr. 11: Okno klienta webové služby..................................................................................22 Obr. 12: Class diagram.........................................................................................................23

xiv

KAPITOLA 1. ÚVOD

1

1 Úvod Webové služby mohou být zjednodušeně popsány následujícím způsobem: „Klient webové služby předává svůj požadavek v textovém formátu poskytovateli webové služby, který odpovídá na požadavek odpovědí rovněž v textovém formátu prostřednictvím webu.“

([1, s. 31], volný překlad) Podíváme-li se na obsah právě zmíněné citace, můžeme si udělat zdánlivou představu o tom, k čemu se dá webová služba použít. Proč bychom však měli usilovat o řešení prostřednictvím webových služeb? Motivací pro zavedení webových služeb může být například skutečnost, že mnohé firmy, které vyvíjí své produkty ke komerčnímu užití (prodeji zákazníkům), je nabízejí jako webové služby. Můžeme tedy spatřovat určitou tendenci k řešení na základě webových služeb. Proč ale zvolit v určitých situacích webové služby spíše než alternativní řešení? Webové služby mohou poskytovat jednodušší rozhraní k našemu softwarovému produktu. Pro uživatele by mělo být snazší orientovat se v tom, co může od webové služby čekat. Webové služby také umožňují provádění distribuovaného výpočtu. Příkladem může být například software Weka4WS, jemuž bude věnována jedna z následujících kapitol. Konečně webová služba by měla být snadno dostupná prostřednictvím zaregistrování v adresáři webových služeb (viz další kapitoly). V této práci se budeme nejprve zabývat popisem webových služeb z hlediska základních principů, na nichž jsou webové služby postavené. Poté bude věnována pozornost spojení webových služeb s data miningem a bude uveden konkrétní příklad data miningového software využívající webové služby. V další části práce bude stručně představen software FAKE GAME. V závěrečné části se tato práce pokusí představit možná řešení webových služeb pro software FAKE GAME.

2

KAPITOLA 2. WEBOVÉ SLUŽBY

2 Webové služby Stejného výsledku, jako za použití webových služeb, lze dosáhnout i prostřednictvím jiných technologií, například RMI, CORBA nebo EJB. Webové služby však mají při srovnání s těmito technologiemi určité výhody [2, s. 6]: •

Díky jazyku XML jsou platformě a jazykově nezávislé.

•

Přenos zpráv pomocí protokolu HTTP.

Na druhé straně, webové služby skýtají i jisté nedostatky oproti alternativním řešením. Jedná se zejména o: •

Ztráta efektivity přenosu vyplývající z faktu, že data jsou přenášena v textovém formátu (XML) a nikoli v proprietárním binárním formátu.

•

Ztráta přizpůsobivosti (versatility). Webové služby nenabízí podpůrné služby typu transakcí, perzistence atd. jako například technologie CORBA.

O uvedených výhodách i nedostatcích bude ještě pojednáno dále v textu. Abychom se mohli věnovat webovým službám sofistikovaným způsobem, bylo by zapotřebí seznámit se se základními prvky webových služeb. Technologie webových služeb je postavena na třech pilířích [12, s. 1]: •

protokol SOAP;

•

jazyk pro popis poskytovaných webových služeb, zvaný WSDL;

•

mechanismus pro nalezení služeb, kde spolu soupeří standardy zvané UDDI a WSIL.

Podívejme se nyní na každý z nich bližším pohledem.

2.1 Technologie využívané webovými službami 2.1.1 SOAP protokol SOAP je protokol představující alternativu pro vzdálené volání procedur (Remote Procedure Call – RPC). RPC však přináší určitá omezení s ohledem na kompatibilitu a bezpečnost [9]. SOAP protokol umožňuje přenos přes protokol HTTP, čímž odstraňuje problémy RPC spojené s obtížnou průchodností přes firewall a proxy servery. SOAP protokol má definovanou určitou strukturu. Elementy SOAP message (zprávy) jsou envelope (obálka), header (hlavička), body (tělo) a fault (chyby). Message musí vždy obsahovat envelope a body, zbylé elementy jsou volitelné. Schématickou strukturu message zachycuje následující kód [9]:

KAPITOLA 2. WEBOVÉ SLUŽBY <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... <soap:Body> ... <soap:Fault> ...

Jak lze vypozorovat, SOAP protokol přenáší data ve formátu XML. Programátor je typicky při psaní webových služeb odstíněn od nutnosti znát podrobnosti protokolu SOAP. 2.1.2 WSDL WSDL je jazyk založený na XML sloužící k popisu webové služby a určení způsobu přístupu k ní. Specifikuje, kde se webová služba nachází a operace, které poskytuje [9]. Stejně jako SOAP protokol, i WSDL se skládá z určitých elementů. Základní struktura WSDL dokumentu, tak jak je znázorněna v [10], vypadá následovně: <definitions> definition of types........ <message> definition of a message.... <portType> definition of a port....... definition of a binding....

Nejdůležitějším elementem je patrně portType, který definuje zprávy a operace webové služby. Zpráva definuje data elementů a operací. Element binding definuje pro každý port, specifikovaný elementem portType, formát zprávy a detaily protokolu. Konečně element types určuje typ dat (prostřednictvím XML Schema), který webová služba využívá.

3

4

KAPITOLA 2. WEBOVÉ SLUŽBY 2.1.3 UDDI a WSIL

UDDI je adresář pro uchovávání informací o webových službách, tedy adresář obsahující rozhraní webových služeb popsaných pomocí WSDL. Prakticky by UDDI mělo fungovat tak, že poskytovatel webové služby zaregistruje webovou službu v UDDI adresáři, a příjemce dané webové služby může po nalezení webové služby v adresáři se službou přímo komunikovat. UDDI je společně vyvíjeno předními společnostmi na trhu IT (například Dell, HP, Sun ad.) [10]. Popis toho, jak konkrétně funguje UDDI lze nalézt např. v [15]. WSIL je společnou snahou IBM a Microsoftu nabídnout alternativu k UDDI. WSIL využívá k referencování webových služeb jazyk XML. Více se lze o WSIL dočíst například v [11]. Webovou službu lze jednoduše zveřejnit (publikovat) do vybraného interního i externího adresáře webových služeb například za pomoci některého administrátorského správcovského rozhraní1. V opačném případě, pokud chceme webovou službu vyhledat, můžeme využít určitého vyhledávače webových služeb2. Webové služby pro aplikaci FAKE GAME (viz dále) budou realizovány v jazyku Java. Nyní bychom se proto měli krátce podívat, jakým způsobem jsou implementovány webové služby v právě v jazyku Java.

2.2 JAX-WS Webové služby v Javě lze realizovat pomocí JAX-WS (Java Api for XML Web Services). Jak název napovídá, rozhraní využívá XML pro spojení mezi webovou službou a klientem webové služby. Konkrétně se jedná o protokol SOAP, který je využit pro realizaci dotazů a odpovědí. Vlastní přenos sítí zajišťuje, jak bylo již uvedeno při obecném popisu webových služeb, protokol HTTP. Rysem rozhraní JAX-WS je platformní nezávislost. V důsledku použití standardních protokolů (HTTP, SOAP, WSDL) nemusí být webová služba, na níž se klient obrací, řešena na platformě jazyku Java. Naopak – na webovou službu se může obracet i klient, který nevyužívá rozhraní JAX- WS [5]. 2.2.1 SOAP protokol Je třeba říct, že přestože SOAP protokol je vcelku komplexní, programátor nemusí znát detaily tohoto protokolu. Rozhraní programátora odstíní od nutnosti znát tento protokol. Při požadavku na webovou službu (method invocation) se požadavek odesílá jako SOAP požadavek (request), naopak odpověď webové služby přichází jako SOAP odpověď (response). V případě elementární webové služby poskytující jedinou metodu, která odpoví na uživatelem zadané jméno pozdravem, lze vidět detaily SOAP protokolu v následujících výpisech.

1 2

Příkladem může být Sun Java System Application Server Admin Console pro server GlassFish. Adresář webových služeb lze prohlížet např. na serveru http://seekda.com.

KAPITOLA 2. WEBOVÉ SLUŽBY SOAP request: <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Header/> <S:Body> <ns2:sayHello xmlns:ns2="http://server/"> Jan

SOAP response: <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:sayHelloResponse xmlns:ns2="http://server/"> Hello Jan

Následující obrázek znázorňuje komunikaci mezi webovou službou a jejím klientem. Obr. 1: Komunikace webové služby

zdroj: převzato z: The Java EE 5 Tutorial: http://java.sun.com/javaee/5/docs/tutorial/doc/

5

6

KAPITOLA 2. WEBOVÉ SLUŽBY 2.2.2 Anotace

Systém anotací obecně poskytuje určité informace (metainformace), které jsou využitelné dalšími knihovnami a nástroji daného jazyka, což se může projevit při chodu programu [16]. Anotace spojené s webovými službami JAX-WS mají za cíl specifikovat metadata spojená s webovými službami a zároveň zjednodušit vývoj a nasazení (deployment) webových služeb. Anotace například slouží k mapování Java kódu do WSDL a xsd souborů [17]. Systém anotací zde využívají programy jako wsgen nebo wsimport. Anotace pro JAX-WS najdeme v balíku javax.jws. 2.2.3 Realizace Při vývoji webových služeb v rozhraní JAX-WS je nutné nejprve definovat třídu, která bude obsahovat anotaci javax.jws.WebService. Tato anotace označuje, že třída tvoří service endpoint implementation. Pomocí programu wsgen jsou poté vytvořeny artifacts potřebné k deployment (nasazení) webové služby. Třída označená anotací javax.jws.WebService musí splňovat určité náležitosti, mezi něž patří zejména následující3: •

předmětné metody webové služby jsou anotovány prostřednictvím anotace javax.jws.WebMethod;

•

předmětné metody musí být public a nesmí být static nebo final;

•

předmětné metody musí mít kompatibilní parametry a návratové hodnoty s JAXB4;

•

implementující třída nesmí být final nebo abstract;

•

třída musí mít defaultní public konstruktor;

•

třída nesmí deklarovat finalize metodu ad.

Následně je vytvořen war archiv, který je nasazen (deploy) na aplikační server. Serverem může být například Apache Tomcat nebo GlassFish. Pro webové služby aplikace FAKE GAME bude zvolen aplikační server GlassFish. Klient, který se připojuje k webové službě, je označen anotací javax.jws.WebReference. Tato anotace specifikuje URI WSDL, který náleží nasazené webové službě. Klient komunikuje s webovou službou prostřednictvím lokálního objektu, který vystupuje jako proxy pro volání vzdálené služby. Tento objekt, tzv. port, je vytvářen programem wsimport. Tímto způsobem dochází k volání webové služby prostřednictvím klienta. Vedle zmíněného řešení využívajícího systém anotací pro vytvoření webové služby a jejího klienta, lze webové služby v Javě realizovat ještě prostřednictvím JAX-RPC. Webové služby na základě JAX-WS jsou novějším řešením a zdá se, že budou mít do budoucna větší podporu ze strany tvůrců řešení pro webové služby v jazyku Java5. Snahou v této práci proto bude zabývat se 3

Plný rozsah podmínek lze najít například na: http://java.sun.com/javaee/5/docs/tutorial/doc. Více o JAXB lze najít na například na: http://java.sun.com/javaee/5/docs/tutorial/doc. 5 Nejen zdrojový kód, ale například také související nástroje, podpora aplikačních serverů, navazující programy atd. 4

KAPITOLA 2. WEBOVÉ SLUŽBY

7

vytvářením webových služby na základě JAX-WS. Možnost realizace webových služeb na základě JAX-RPC ponecháme stranou.

2.3 Webové služby ve spojení s data miningem Webové služby zasahují zřejmě do širokého spektra oblastí využití. Jednou z oblastí může být rovněž data mining (DM). Základní pohled na využití webových služeb pro účely DM lze najít například v [1]. Pro hrubý nástin využití webové služby pro DM můžeme vyjít z příkladu uvedeném v daném sborníku. Potřebovali bychom postavit regresní model pro námi dodaná data. V ideálním případě bychom dodali strukturovaná data ve formátu XML a výsledný regresní model by se nám vrátil opět ve formátu XML. Webové služby by nejen měli zajistit, že požadavek klienta webové služby a odpověď patřičné webové služby jsou strukturované, ale navíc také, že doba mezi požadavkem a odpovědí je relativně krátká. Webové služby lze patrně efektivně využít pro potřeby DM. Existují však i otevřené otázky, mezi něž můžeme zařadit dle [1] následující: •

bezpečnost dat;

•

asynchronní webové služby;

•

stavové webové služby (Data Mining State Session Management);

•

WS-Resource Framework.

Některým aspektům se budeme ještě věnovat dále, zdroje informací k ostatním lze nalézt například v [1]. Nyní se podívejme na konkrétní praktické využití webových služeb pro potřeby DM. Tato práce neusiluje o popsání všech existujících řešení. Věnuje se přiblížení jednoho konkrétního řešení – Weka4WS.

8

KAPITOLA 3. PŘÍKLAD WEBOVÝCH SLUŽEB PRO DATA MINING

3 Příklad webových služeb pro data mining 3.1 Weka4WS 3.1.1 Úvod Weka4WS, jako rozšíření DM software Weka, umožňuje rozdělit DM proces na lokální a distribuované provádění. Webové služby jsou zde využity právě k distribuovanému výpočtu. Verze 2.1 Weka4WS je spojena s Wekou ve verzi 3.14.12. Samotná Weka je rozdělena do čtyř samostatných částí. Weka4WS přímo rozšiřuje jednu z těchto částí, modul Explorer tím, že do něj přidává možnost vzdáleného provádění DM operací přes webové služby spolu s možností lokálních DM výpočtů. Modul Explorer Weky poskytuje několik DM operací, které jsou dohromady uvedeny na panelu Weka Knowledge Explorer. Patří sem preprocessing (předzpracování dat), classification (klasifikace), clustering (klustry), association (asociace), select attributes (výběr atributů) a visualize (vizualizace). Weka nabízí mnoho algoritmů implementovaných v jazyku Java, které jsou přístupné prostřednictvím GUI. Stejné operace jako výše uvedené najdeme také ve Weka4WS. Filozofie frameworku je založena na využití gridů6. Dříve než se dostaneme k samotnému popisu Weka4WS frameworku, bylo by namístě zmínit se právě o koncepci, na které je tento framework postaven. Tímto konceptem je Globus Toolkit 4.0.x. 3.1.2 Globus Toolkit 4.0.x (GT4) Protože GT4 architektura je komplexním konceptem, který je poskládán z jednotlivých dílčích částí, podívejme se schematicky na jejich vzájemnou vazbu:

6

Více o gridech lze dále dohledat např. v: Foster I., Kesselman C., Tuecke S. The Anatomy of the Grid: Enabling Scalable Virtual Organizations. http://www.globus.org/research/papers/anatomy.pdf nebo v: Foster I., Kesselman C., Tuecke S., Nick J. The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. http://www.globus.org/research/papers/ogsa.pdf.


9

Obr. 2: Vazby mezi komponentami GT4

zdroj: převzato z: The Globus Toolkit 4 Programmer's Tutorial: http://gdp.globus.org/gt4-tutorial/multiplehtml/ch01s04.html

Na obrázku vidíme jako základ webové služby, které jsou rozšířeny o stavové webové služby (webové služby schopné si zapamatovat stav mezi dvěma jejich vyvoláními – viz jeden z bodů v předchozím oddílu). Stavové webové služby odstraňují jeden z nedostatků resp. charakteristických rysů webových služeb, totiž že webové služby jsou v zásadě bezestavové7. Webové služby schopné zapamatovat si stav jsou vyžadovány levou větví na zmíněném obrázku. Open Grid Services Architecture (OGSA), vedle toho, že vyžaduje po webových službách, aby byly stavové, definuje především společnou, jednotnou a otevřenou architekturu pro aplikace založené na gridech. Prakticky se tento cíl projevuje ve snaze identifikovat a standardizovat všechny služby, s nimiž se lze setkat v každé gridově orientované aplikaci (job management services, resource management services, security services ad.) [2].

7

Ačkoli, webové služby mohou být teoreticky i stavové [2].

10


Komponentou definující stavové webové služby je Web Services Resource Framework (WSFR). Hlavní funkcí WSFR je právě zmíněná specifikace stavovosti webových služeb. Podíváme-li se na vzájemný vztah WSFR a OGSA, můžeme ve shodě s oficiální dokumentací GT4 [2] říci, že zatímco OGSA je architekturou, WSFR poskytuje infrastrukturu, na níž je tato architektura postavena. V neposlední řadě je třeba zmínit, že vedle GT4 existují i další architektury, např. WSFR.net8. Samotnou GT4 architekturu z hlediska konkrétní implementace zachycuje následující obrázek: Obr. 3: GT4 architektura

zdroj: převzato z: The Globus Toolkit 4 Programmer's Tutorial: http://gdp.globus.org/gt4tutorial/multiplehtml/ch01s04.html

8

Bližší informace k WSFR.net lze najít například na: http://www.cs.virginia.edu/~gsw2c/wsrf.net.html.


11

Čára přibližně v dolní třetině obrázku odděluje komponenty, které nemají vztah k webovým službám od těch, které webové služby využívají. Z obrázku je patrné, že implementace není vázána pouze na jeden konkrétní jazyk, i když středem našeho zájmu bude pouze komponenta implementovaná v jazyku Java (Java WS Core). Tato komponenta je pro nás důležitá zejména ze dvou hledisek. Za prvé, za předpokladu, že bychom uvažovali o zkonstruování složitějšího systému založeném na použití gridů, který by integroval všechny komponenty s našimi službami (rozhodli-li jsme se pro webové služby realizované v jazyku Java), potřebovali bychom znalost Java WS Core k tomu, abychom jejím prostřednictvím vše dohromady „poslepovali“ [2]. Druhým, pro nás nyní podstatnějším důvodem je, že Java WS Core je využita pro účely Weka4WS. 3.1.3 Weka4WS framework Gridy umožňují rozdělit výpočetní výkonu mezi vícero počítačů, zatímco „bezgridová“ Weka provádí veškeré výpočetní operace lokálně (na lokálním počítači). Weka4WS zachovává provádění fází předzpracování dat a vizualizace na serveru (lokálně), zatímco algoritmy pro klasifikaci, clustry a asociační pravidla mohou být delegovány na vzdálené (remote) gridy. Algoritmy jsou zpřístupněny přes webové služby a takové webové služby jsou nasazeny na konkrétní gridy [3]. V obecné architektuře tak rozlišuje Weka4WS tři typy uzlů: •

storage nodes (paměťové uzly);

•

computing nodes (výpočetní uzly);

•

user nodes (klientské uzly).

User nodes představují lokální počítače, na kterých je nainstalován software pro přístup klienta k webové službě. Computing nodes představují jednotky, na nichž jsou prováděny vzdálené DM úlohy v podobě webových služeb. Storage nodes pak uchovávají vstupní data pro DM. Všechny typy uzlů schématicky znázorňuje následující obrázek:

12


Obr. 4: Architektura Weka4WS

zdroj: převzato z: Talia D., Trunfio P., Verta O.: Weka4WS: a WSRF-enabled Weka Toolkit for Distributed Data Mining on Grids, s. 3

GUI rozšiřuje panel Weka Explorer a umožňuje provádět DM operace lokálně i vzdáleně. Panel Explorer je zachycen na obrázku č. 5. Lokálně zajišťuje DM operace Weka Library. Vzdáleně má tento úkol na starosti Client Module, který vystupuje v roli prostředníka mezi GUI a webovými službami. Webové služby vystavují DM algoritmy poskytované Weka Library. Webové služby jsou samozřejmě v souladu s frameworkem WSRF. Poslední komponentou je FTP server resp. GripFTP server zajišťující přístup k datům určeným pro DM.


13

Obr. 5: Explorer panel Weka4WS

zdroj: Weka4WS: http://grid.deis.unical.it/weka4ws/index.html?page=main.html§ion=screenshots

Webové služby mají definovaný okruh operací, které se standardně provádí v okamžiku, kdy směřuje požadavek na vzdálené provedení DM operace. Do této skupiny se řadí operace uvedené v následujícím přehledu: •

createResource;

•

subscribe;

•

destroy;

•

classification;

•

clustering;

•

associationRules.

První tři operace jsou spojeny s požadavky kladenými na webové služby frameworkem WSRF, zbylé tři operace se týkají vlastních DM operací. Classification zpřístupňuje algoritmy Weka Library (v době psaní této práce 71 algoritmů), clustering a associationRules nabízí clustering a association rules algoritmy z Weka Library (v době psaní práce 5 resp. 2 algoritmy) [3].

14


Webové služby v této koncepci obsahují sadu vstupních parametrů. Těchto je několik, přičemž tři jsou společné všem webovým službám. Jedná se o: •

algorithmů;

•

arguments;

•

dataSet.

Algorithm specifikuje Java třídu z Weka Library, která se týká dané operace. Příkladem může být weka.classifiers.trees.J48. Arguments představují parametry, které jsou předávány algoritmům, například C 0.25 -M 2. DataSet specifikuje URL dat, která jsou určena k DM, například gsiftp://hostname/path/ad.arff . Podrobnější popis volání webových služeb lze najít v [3]. Pokud bychom se v závěru podívali na Weka4WS, mohli bychom dle [6] vyčlenit následující charakteristiky: •

možnost souběžného vzdáleného vykonávání několika úloh;

•

možnost pozastavení běhu vzdálené úlohy;

•

komprese vstupních dat za účelem dosažení vyšší přenosové rychlosti;

•

podpora pro autorizaci a autentizaci v rámci aplikace;

•

detailní logging z hlediska událostí na klientovi i na službě;

•

plná podpora JDBC, preprocessingu a visualizace dat;

•

kontrola (check) dostupnosti Globus kontejneru, GridFTP, uživatelských oprávnění, kompatibility verzi mezi klientem a službou ad.

Souhrnně lze tedy konstatovat, že Weka4WS představuje řešení využívající stavové webové služby, v němž jsou webové služby využívány k provádění distribuovaného výpočtu. Zároveň je zde otevřena možnost k asynchronním webovým službám, neboť DM operace lze provádět na několika vzdálených výpočetních jednotkách s určitou možností řízení jejich počtu. Konečně, při spuštění Weka4WS jsou případně vyžadovány autentizační údaje (credentials). Weka4WS tak určitým způsobem adresuje většinu otevřených otázek, jak byly uvedeny v oddílů 2.3. Určitý rys uvedený výše využijeme později při řešení webových služeb pro aplikaci FAKE GAME. Konkrétně využijeme možnosti vzdáleného provádění výpočtu (vizualizace a tvorba modelu – viz dále). Na rozdíl od Weka4WS však budou naše webové služby realizovány jako bezestavové. Pro požadavky kladené na webové služby pro aplikaci FAKE GAME v tomto stupni realizace se jeví bezestavové služby jako dostatečné. Z podobných důvodů nebudeme usilovat ani o asynchronní řešení, ani o zabezpečení webových služeb.

KAPITOLA 4. APLIKACE FAKE GAME

15

4 Aplikace FAKE GAME 4.1 Úvod Tato práce má za cíl vytvořit v praktické části podobu programu, ve které bude zpřístupněna aplikace FAKE GAME přes webové služby. Dříve, než se budeme věnovat popisu vlastního řešení, bylo by na místě zmínit se krátce o samotném DM software FAKE GAME. FAKE GAME je DM nástroj vyvíjený skupinou Výzkumná inteligence na katedře Počítačů ČVUT. Zdrojový kód FAKE GAME je k dispozici pod licencí GPL v.2 ke stažení na stránkách Sourceforge.net [8]. FAKE GAME využívá k vytváření DM modelů algoritmy přirozeného vývoje. Zahrnuje několik preprocessingových, optimalizačních a vizualizačních metod s cílem zredukovat proces hledání znalostí. Vytěžování dat je v aplikaci automatizováno [6]. FAKE GAME byl poprvé představen v roce 2006 v disertační práci [4], která definovala framework celé aplikace. Od té doby je aplikace nepřetržitě vyvíjena. Základní programové okno aplikace FAKE GAME zachycuje následující obrázek:

16

KAPITOLA 4. APLIKACE FAKE GAME Obr. 6: Hlavní okno aplikace FAKE GAME

zdroj: vlastní

4.2 Programové rozhraní FAKE GAME Zdrojový kód je možné stáhnout z centrálního úložiště například přes Subversion. Podporováno je i CVS. Vše existuje pro operační systémy Windows i operační systémy unixového typu. Aplikace obsahuje více než sto balíků. Hlavní třída aplikace se nazývá GMDHtree.java a najdeme ji v balíku game.gui. Tato třída tvoří základní východisko pro jednu z implementací webových služeb pro aplikaci FAKE GAME realizovaných v této práci. Z hlediska dalších balíků, které se přímo uplatní při implementaci webových služeb, jsou vedle game.gui důležité zejména balíky game.data, game.data.visualizedata a game.models. Práce s ostatními balíky je pouze nepřímá či zprostředkovaná. Třidy v balíku game.data se starají o programovou reprezentaci vstupních dat. Komponenty v game.data.visualizedata vytváří grafickou reprezentaci vstupních dat. Komponenty v game.models mají na starosti vytváření a správu modelů vstupních dat.

KAPITOLA 5. VLASTNÍ ŘEŠENÍ WEBOVÝCH SLUŽEB

17

5 Vlastní řešení webových služeb Webové služby v této práci byly vyvíjeny pod operačním systémem Windows, s využitím Java 1.6 a NetBeans IDE 6.1. Webové služby jsou postaveny na architektuře klient server, kde klientem je program, který spouští uživatel a serverem je program, který zpřístupňuje funkcionalitu aplikace FAKE GAME. V této práci jsou webové služby realizovány dvěma možnými způsoby. V první variantě je volána aplikace FAKE GAME z příkazového řádku. V druhé případě se pracuje přímo se zdrojovým kódem FAKE GAME.

5.1 Řešení s příkazovým řádkem 5.1.1 Popis Webové služby jsou v tomto případě realizovány bez přístupu ke zdrojovému kódu FAKE GAME. Východiskem je skutečnost, že FAKE GAME při buildu vytváří automaticky také spustitelný archiv jar. Ten lze volat s parametry příkazové řádky operačního systému. Webová služba tedy přistupuje k FAKE GAME zprostředkovaně. V kódu webové služby je přímo zadán příkaz s možností zvolit parametry v závislosti na preferenci klienta. Klient vybírá vstupní soubor s daty k DM operacím. Dále si může zvolit ze tří možných konfigurací (standard, linear, quick), čímž zvolí odpovídající konfigurační soubor (std.cfg, linear.cfg, quick.cfg). Případně by mohl vybrat také vlastní konfigurační soubor. Nakonec ještě stanoví počet vytváření ensemble modelů. Klientská část aplikace je znázorněna na obr. č. 7. Výslednou zprávu o výsledku DM operací zpřístupňuje uživateli v záložce Output.

18


Obr. 7: Okno klienta webové služby

zdroj: vlastní

Serverová část aplikace přebírá načtená data včetně zadaných parametrů a zavolá nad nimi aplikaci FAKE GAME. Po provedení DM operací vytvoří html soubor s vyhodnocením, který vrátí klientovi.


19

Výše uvedený proces znázorňuje následující graf. Obr. 8: Use Case diagram

zdroj: vlastní

5.1.2 Implementace Hlavními třídami aplikace jsou třídy Frame1_new a FakeWSServer_new. Třída Frame1_new vytváří klientské grafické uživatelské rozhraní (gui) a rovněž přistupuje k metodám webové služby. K metodám webové služby přistupuje třída přes lokální proxy objekt. Pomocné metody jsou vyčleněny do třídy MyUtil (například centrování obrazovky ad.). FakeWSServer_new je implementační třídou pro webové služby. Třída je označena anotací @WebService a jednotlivé metody webové služby jsou označeny anotacemi @WebMethod. Třída využívá třídu StreamGobbler k zadání příkazu pro příkazovou řádku. Serverová část aplikace je nasazena na aplikačním serveru GlassFishV2.

20


Implementační detaily zachycuje class diagram.

Obr. 9: Class diagram

zdroj: vlastní

Webová služba je umístěna na školním serveru9 i na lokálním počítači. Nevýhodu tohoto řešení je zejména malá možnosti konfigurace.

5.2 Řešení s využitím zdrojového kódu 5.2.1 Popis Webová služba v tomto řešení využívá zdrojový kód aplikace FAKE GAME. Z toho důvodu je nutné, aby v Libraries projektu byl zahrnut jar archiv FAKE GAME vč. všech jar archivů, které FAKE GAME využívá10. Snahou bylo, aby vytvářená aplikace pracovala s kódem aplikace FAKE GAME, avšak nijak ho nemodifikovala. Vzhledem k rozsáhlosti aplikace FAKE GAME není přes webové služby zpřístupněna veškerá funkcionalita aplikace. Prostřednictvím klienta lze načíst zdrojový soubor s daty určenými pro DM. Vedle prostého načtení do paměti programu lze rovněž data zobrazit (vizualizovat) několika možnými způsoby, například histogramem nebo pomocí means grafu. 9

Více viz Dodatek C. Projekt je vytvořen pomocí buildovacího nástroje Ant. Všechny závislosti jsou proto řešeny natažením jar archivů do Libraries. Jde tedy o odlišný přístup vzhledem k nástroji Maven, který řeší závislosti v hlavním programovém xml souboru s extenzí pom. 10


21

Před sestavením modelu je třeba provést rozdělení vstupních dat na dvě části – trénovací a testovací set. Trénovací část bude vstupem pro tvorbu modelu. Na testovací části se posléze výsledky vyhodnotí. V programu lze vytvořit celkem čtyři modely: lineární, polynomiální, sigmoid a gaussian model. Výsledná zpráva se po vytvoření modelu ukládá do souboru, k jehož uložení program uživatele vyzve. Základní schéma komunikace v tomto řešení zobrazuje následující obrázek.

Obr. 10: Use Case diagram

zdroj: vlastni

22


Hlavní okno klientské části programu je možné vidět na následujícím obrázku.

Obr. 11: Okno klienta webové služby

zdroj: vlastní

5.2.2 Implementace Hlavními třídami vytvářené aplikace jsou ClientJFrame a Wsp. Třída ClientJFrame vytváří klientské grafické uživatelské rozhraní (gui) a zároveň přistupuje k metodám webové služby. K metodám webové služby přistupuje třída přes lokální proxy objekt. Pomocné metody jsou vyčleněny do samostatné třídy MyUtil. Implementační třídou pro webové služby je třída Wsp. Třída je označena anotací @WebService a jednotlivé metody webové služby jsou označeny anotacemi @WebMethod. Třída importuje všechny potřebné třídy aplikace FAKE GAME.


23

Implementaci ukazuje následující class diagram.

Obr. 12: Class diagram

zdroj: vlastní

Hlavní nevýhodou tohoto řešení je nemožnost uvedení webové služby do provozu na unixovém školním serveru. Důvodem je značná provázanost DM funkčnosti s grafickým uživatelským rozhraním (gui) ve zdrojovém kódu aplikace FAKE GAME. Webovou službu lze tak spustit pouze na lokálním počítači (localhost).

24

KAPITOLA 6. TESTOVÁNÍ

6 Testování Aplikace byla v obou variantách testována pomocí JUnit testů. Aplikace není JUnit testy pokryta zcela, nicméně pro většinu kódu jsou testy napsány. Testy byly provedeny pro klientskou i serverovou část zvlášť. Pomocné soubory k otestování jsou uloženy v adresářích příslušného projektu – viz obsah přiloženého CD. Testy lze spustit z adresáře projektu příkazem ant test, případně před vytvořením jar archivu a javadocu lze testy spustit příkazem ant default. Aplikace byly testována na platformě Java JDK 1.6.0_13 resp. 1.6.0_07 a na aplikačním serveru GlassFishV2 na lokálním počítači (http://localhost:8080) resp. na školním serveru http://kovarik.felk.cvut.cz. Webové služby na školním serveru jsou blíže popsány v Dodatku C této práce.

KAPITOLA 7. ZÁVĚR

25

7 Závěr Tato práce se nejprve zabývala popisem webové služby a představila hlavní principy jejího fungování. Následně byla věnována pozornost řešení webových služeb na platformě jazyka Java. Konkrétně jsme popsali řešení založené na JAX-WS. V rámci srovnání s jinými existujícími technologiemi byly představeny webové služby založené na grid technologii. Cíle práce z hlediska implementace vlastního řešení byly splněny. V práci byly postupně implementovány dva alternativní přístupy k řešení webových služeb pro aplikaci FAKE GAME. V prvním případě se funkčnosti aplikace FAKE GAME využívá nepřímo spouštěním aplikace FAKE GAME přes příkazový řádek operačního systému. Webová služba dovoluje zvolit jednu z přednastavených konfigurací11 a na základě načtených dat vytváří model. Výsledek se ukládá do html souboru. V druhém případě jsou webové služby realizovány v interakci se zdrojovým kódem aplikace FAKE GAME. Webová služba umožňuje zobrazit (vizualizovat) načtená data a následně vytvořit na základě dat jeden z možných modelů. Výsledek je poté uložen do souboru. Obě řešení mají své přednosti a nedostatky. První řešení umožňuje fungování webové služby pro aplikaci FAKE GAME na školním unixovém serveru. Hlavní nevýhodou řešení je omezená možnost konfigurace. Toto řešení by však nemělo být tolik náročné na výpočetní zdroje, neboť na serveru nedochází k práci s grafickými knihovnami. Druhé řešení umožňuje v mnohem větší míře konfigurovat a využívat funkčnost aplikace FAKE GAME. Nevýhodou je omezená praktická využitelnost, neboť webovou službu nelze nasadit na školní unixový server resp. jiný unixový server. Tomu brání značná provázanost DM funkčnosti aplikace FAKE GAME s grafickým uživatelským rozhraním (gui).

7.1 Možná vylepšení a rozšíření Webové služby nevyužily plně veškerou funkčnost aplikace FAKE GAME. Dalším možným rozpracováním by se tak mohlo stát rozšíření možnosti předávat více parametrů webové službě od jejího klienta. Druhé řešení v této práci, díky rozsáhlosti zdrojového kódu aplikace FAKE GAME a zčásti chybějící dokumentaci ke zdrojovému kódu, rovněž nepokrylo veškerou funkčnost aplikace FAKE GAME. I zde se otevírá možnost doplnit webové služby o další funkce a s tím související možnosti konfigurace. V každém případě by pro toto řešení bylo třeba upravit zdrojový kód aplikace FAKE GAME, aby se oddělila funkčnost od grafického uživatelského rozhraní.

11

Teoreticky lze zvolit i vlastní konfiguraci – viz výše.

26

KAPITOLA 8. LITERATURA

8 Literatura [1] Proceedings of the Second Annual Workshop on Data Mining Standards, Services and Platforms. Ed. R. Grossman. Seattle: University of Illinois at Chicago & Open Data Partners, 2004. 55 s. [2] SOTOMAYOR, B. The Globus Toolkit 4 Programmer's Tutorial. The Globus Alliance. University of Chicago, Department of Computer Science, 2004, 2005. 177 s. [3] TALIA, D., TRUNFIO, P., VERTA, O. Weka4WS: a WSRF-enabled Weka Toolkit for Distributed Data Mining on Grids. Rende: DEIS, University of Calabria. 12 s. [4] KORDÍK P. Fully Automated Knowledge Extraction using Group of Adaptive Models Evolution. PhD. Thesis. Praha: České vysoké učení technické, 2006. [5] Sun Microsystems. Web Services. http://java.sun.com/javaee/5/docs/tutorial/doc/bnayk.html (2009-4-20). [6] Grid Computing Lab. Weka4WS. http://grid.deis.unical.it/weka4ws/ (2009-5-10), http://weka4ws.wordpress.com/about/ (2009-5-11). [7] Computational Intelligence Group. Fake Game Project. http://neuron.felk.cvut.cz/game/ (2009-5-14). [8] SourceForge, Inc. fakegame. http://sourceforge.net/projects/fakegame/ (2009-5-5). [9] W3Schools. Soap Tutorial. http://www.w3schools.com/soap/default.asp (2009-5-12). [10] W3Schools. WSDL Tutorial. http://www.w3schools.com/wsdl/default.asp (2009-5-8). [11] IBM. Web Services Inspection Language. http://www.ibm.com/developerworks/library/specification/ws-wsilspec/ (2009-5-10). [12] DOHNAL, F. Web services, Praha: České vysoké učení technické, s. 10. [13] Sun Microsystems. Annotations. http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html (2009-6-26). [14] IBM. JAX-WS annotations. http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp (2009-6-26). [15] IBM. Understanding WSDL in a UDDI registry, Part 1. http://www.ibm.com/developerworks/webservices/library/ws-wsdl/ (2009-6-26). [16] JavaWorld. When Runtime.exec() won't. http://www.javaworld.com/javaworld/jw-122000/jw-1229-traps.html?page=1, (2009-6-28).

DODATEK A. UŽIVATELSKÁ / INSTALAČNÍ PŘÍRUČKA

27

A Uživatelská / instalační příručka Instalace Serverovou část aplikace je třeba nasadit (deploy) na aplikační server. Archiv war lze nasadit například z webového rozhraní aplikačního serveru GlassFish (admin konzole implicitně poslouchá na portu 4848). V prostředí NetBeans lze provést příkazem Undeploy and Deploy z kontextové nabídky. Klientská část aplikace má vytvořenu web service reference na WSDL soubor, který poskytuje serverová část. Umístění WSDL souboru na serverové části lze zjistit například opět z webového rozhraní GlassFish. Aplikaci lze spoustět z vývojového prostředí nebo lze spustit jar archiv umístěný v adresáři /dist klientské části. V řešení, v němž webová služba spouští FAKE GAME z příkazové řádky, je třeba zkopírovat jar archiv fake-core-1.0-SNAPSHOT.jar (viz obsah přiloženého CD) do adresáře $GLASSFISH_HOME\domains\domain1\config, kde $GLASSFISH_HOME je místo, kde je GlassFish nainstalován (například c:\glassfish-v2ur2\). Místo domain1 může být jiná existující doména. Konfigurační soubory (viz obsah přiloženého CD) jsou v adresáři $GLASSFISH_HOME\ domains\domain1\config\cfg. Pomocné soubory se ukládají do adresáře $GLASSFISH_HOME\domains\domain1\config\data.

Návod k uživatelskému ovládání programu Řešení 1 Je nutné nejprve vybrat vstupní soubor a zvolit konfiguraci. Poté je možné spustit výpočet. Výsledek se ukládá do panelu Output a také do souboru na lokálními disku. Řešení 2 Nejprve je třeba nahrát data – příkaz Load. Poté lze vstupní data kdykoli vizualizovat. Pro vytvoření modelu je vhodné nedříve rozdělit vstupní data na trénovací a testovací set – příkaz Save training and testing set. Po uložení vyzve program k načtení trénovacího setu. Poté se model vytvoří výběrem jednoho z možných modelů v menu Models. Výsledek se ukládá do souboru na lokálním disku.

28

DODATEK B. OBSAH PŘILOŽENÉHO CD

B Obsah přiloženého CD Řešení 1 •

Fake_WSklient

/xml-resources - WSDL a XSD soubor /dist - spustitelný jar archiv a dokumentace javadoc test_readFile.txt - slouží pro JUnit testy iris_moje.txt - zdrojová data iris_moje_fakegame_odpoved.html - příklad výstupu programu Help.txt - text pro okno nápovědy

•

Fake_WSserver

/dist test_writeFile.txt

•

fake-core-1.0-SNAPSHOT.jar

•

linear.cfg, quick.cfg, std.cfg, units.cfg, game.xcfg

- war soubor a javadoc dokumentace - slouží pro JUnit testy - jar archiv s FAKE GAME - konfigurační sobory

Řešení 2 •

wa_2c

/xml-resources /dist test_readFile.txt iris_v2.txt

- WSDL a XSD soubor - spustitelný jar archiv a dokumentace javadoc - určen pro JUnit testy - zdrojová data

•

wa_2_1

/dist /data test_loadData.txt

- war soubor a javadoc dokumentace - testovací soubor pro JUnit testy - určen pro JUnit testy

DODATEK C: WEBOVÉ SLUŽBY NA ŠKOLNÍM SERVERU

29

C Webové služby na školním serveru Školní server běží pod operačním systémem Debian Lenny s jádrem 2.6.24-1-686-bigmem. URL serveru je http://kovarik.felk.cvut.cz, IP adresa je 147.32.83.25. Pro účely webových služeb je na serveru zprovozněn aplikační server GlassFishV2. GlassFish má na serveru vyhrazen porty 8080 a 8180. Na druhém portu je zpřístupněna webová administrátorská konzole. Tento port lze změnit příkazem asadmin set server.http-service.http-listener-admin-listener.port=cislo_portu. Na aplikačním serveru je vytvořena doména (může jich být více). Defaultně se vytváří doména s názvem domain1. Doména se spustí příkazem asadmin start-domain název_domény, zastaví se příkazem asadmin stop-domain název_domény. Webovou službu lze umístit na GlassFish tak, že do adresáře $GLASSFISH_HOME/domains/nazev_domeny/autodeploy umístíme war archiv s webovou službou. Poté bychom měli být schopni zobrazit ve webovém prohlížeči WSDL dané webové služby ve formátu http://kovarik.felk.cvut.cz:8080/adresar_ws/nazev_ws?wsdl, například http://kovarik.felk.cvut.cz:8080/Fake_WSserver/FakeWSserver_newService?wsdl.

Webové služby aplikace FAKE GAME

Recommend Documents