České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Studentova Berlička III Bc. Luděk Chmurovský
Vedoucí práce: Ing. Jiří Chludil Studijní program: Elektrotechnika a informatika, strukturovaný magisterský Obor: Výpočetní technika květen 2010
Poděkování Na tomto místě bych rád poděkoval vedoucímu mé diplomové práce Ing. Jiřímu Chludilovi za vstřícné konzultace. Jiřímu Hunkovi za pomoc s tímto projektem a Romanovi Hákovi za neocenitelnou pomoc při studiu.
v
vi
Prohlášení Prohlašuji, že jsem svou diplomovou 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 14.5.2010
...............................................
vii
viii
Abstract The focus of this work is to coordinate and define the rules for design and implementation of a new service center project for Studentova berlička. Furthermore, this thesis deals with the way of linking of external modules with a new functionality for project Studentova berlička. The method of interconnection is based on web services. The text describes the web services, through which it will be possible to remove the shortcomings of the current version of project Studentova berlička. Web interface will ensure easy portability of the information system on mobile platforms and ergonomics for the further development of the system.
Abstrakt Těžištěm této práce je zkoordinovat a vymezit jasná pravidla pro návrh a implementaci nového centra služeb pro projekt Studentova berlička. Dále se tato práce zabývá způsobem propojení externích modulů s novou funkčností projektu Studentova berlička. Způsob propojení je řešen rozhraním založeným na webové službě. Text práce popisuje webové služby, díky kterým bude možné odstranit nedostatky současné verze projektu Studentova berlička. Webové rozhraní zajistí informačnímu systému snadnou portabilitu na mobilní platformy a ergonomii pro další rozvoj systému.
ix
x
Obsah Seznam obrázků 1. Úvod 1.1 Studentova berlička 1.2 Historie vývoje 1.3 Souběžně vyvíjené projekty 1.3.1 Generátor testů 1.3.2 Automatické vyhodnocení testů 1.3.3 Centrum služeb 2. Analýza 2.1 Rozbor architektury 2.2 Modely architektur 2.3 Technologie SOA 2.3.1 CORBA 2.3.2 RMI 2.3.3 XML-RPC 2.3.4 SOAP 2.3.5 REST 3. Implementace 3.1 Webové služba 3.1.1 Části webové služby¨ 3.1.2 Operace webových služeb¨ 3.2 Protokol SOAP 3.3 WSDL 3.4 UDDI 3.5 Zabezpečení 3.5.1 Zabezpečující protokol HTTPS 3.5.2 Zabezpečení webové služby 4. Tutoriál
xi
5. Závěr 5.1 Navazující práce 5.2 Týmová spolupráce 6. Použité zkratky, vysvětlení pojmů 7. Obsah CD 8. Použitá literatura Příloha 1- Tutoriál
xii
Seznam obrázků [1]. Prvotní systém Jagu I – menu [2]. Prvotní systém Jagu I – zadávaní hodnot [3]. Současná verze projektu Studentova berlička [4]. Schéma kooperace souběžně vyvíjených projektů [5]. Schéma MVC Zdroj: http://www.moock.org/lectures/mvc/
[6]. Schéma propojení Klient-Server a Peer-to-Peer Zdroj: http://blog.gogrid.com/2009/05/07/peer-to-peer-is-not-cloud-computing-but.../
[7]. Model CORBA [8]. RMI Model [9]. Schéma webové služby Zdroj: http://juddi.apache.org/docs/3.0/userguide/html_single/
[10]. Struktura SOAP zprávy Zdroj: http://skripsiatl.blog.binusian.org/2009/11/26/pro-wcf-practical-microsoft-soa-implementation/
[11]. Vztah tří základních technologií webových služeb Zdroj: http://www.kosek.cz/diplomka/html/websluzby.html
[12]. Struktura dokumentu WSDL. Zdroj: http://en.wikipedia.org/wiki/Web_Services_Description_Language
[13]. Struktura registru UDDI Zdroj: http://archive.devx.com/xml/articles/sm100901/sm100901-3.asp
xiii
xiv
1. Úvod Tato práce vychází z diplomové práce kolegy Jiřího Hunky (4) a navazuje na bakalářskou práci Marka Sachy (18). Jiří Hunka během svého působení na ČVUT FEL navrhl a implementoval informační systém „Studentova berlička“ (22), který usnadňuje elektronickou komunikaci mezi studenty a jejich vyučujícími. Kolega Marek Sacha ve své práci popsal technologii, kterou je možné propojit stávající verzi informačního systému s rozšiřujícími externími aplikacemi. Projekt Studentova berlička vznikl pod odborným vedením Ing. Jiřího Chludila, jako jednoduchý nástroj pro zefektivnění administrativních úkonů nutných pro vedení cvičení, jako je například sledování docházky, hodnocení testů studentů nebo zadávaní semestrálních prací. Systém se od svého vzniku dočkal mnoha dalších přepracování a rozšíření funkčnosti. Tak se z původně primitivní aplikace stal komplexní nástroj pro potřeby studentů i vyučujících. Tento nástroj má bohužel i několik nedostatků, které bude pro plnohodnotné nasazení potřeba odstranit. Aplikace není implementována modulárně ani objektově, což snižuje transparentnost zdrojových kódů, pružnost úprav a změn stávající funkčnosti, včetně jejího rozšíření. Dalším velkým nedostatkem je úzké svázání aplikace s datovým úložištěm. Navržené uživatelské rozhraní, které si bohužel u některých uživatelů nezískalo příliš velkou oblibu, je pevně spjato s aplikační logikou systému. Proto architektura systému neumožňuje snadno přizpůsobovat prezentace dat konkrétním požadavkům. Nejpalčivějším nedostatkem současné verze je však problematické napojení externích modulů. Aktuálně jsou připravovány moduly pro generování testů, pro automatické vyhodnocení testů a pro management semestrálních prací. Za současného stavu si zapojení každého z uvedených modulů vyžaduje nekoncepční a zásadní změnu zdrojového kódu. Na většinu uvedených problémů již poukazuje Jiří Hunka ve své diplomové práci, ve které navrhuje kompletní přepracování architektury jádra a datového úložiště. S tímto závěrem plně souhlasím. Těžištěm této práce je zavést a zdokumentovat vhodné a dostupné postupy, v návaznosti na práci Marka Sachy (18), které by všechny uvedené nedostatky potlačily.
1
1.1 Studentova berlička Původní systém dostal název Studentova berlička, protože vznikal s cílem: •
pomoci studentům získat informace o dosažených bodech z cvičení,
•
zjednodušit komunikaci mezi vyučujícím a studentem a
•
zjednodušit administrativu s vedením cvičení.
Studentova berlička se v průběhu let vyvinula od primitivní evidence docházky a bodování aktivity v hodinách, až po komplexní nástroj pro kontrolu a evidenci práce studentů na cvičeních. Nástroj zahrnuje sledování docházky na cvičení, aktivitu studentů v hodinách, evidenci výsledků testů a zadávání a následné hodnocení semestrálních prací. Systém v současné podobě disponuje webovým rozhraním, které bylo navrženo na míru, pro základní pokrytí prvotních požadavků. Bylo rozhodnuto, že vývoj projektu Studentova berlička se nadále nebude ubírat směrem úprav stávajícího systému, ale bude kompletně přepracováno celé jádro, na základě analýzy stávající funkčnosti a potřeb uživatelů. Nový návrh a implementace umožní dalším vývojářům programovat univerzálnější a platformě přenositelnější uživatelská rozhraní s větší efektivitou a menší časovou náročností. Vydání se směrem k novému propracovanějšímu informačnímu systému s sebou nese velký rozsah práce. Vývoj nového projektu, pracovně nazvaného „Centrum služeb“, bude rozdělen do tří samostatných prací. Námětem těchto prací bude především: •
reorganizace datového úložiště,
•
návrh nového flexibilnějšího jádra nezávislého na druhu datového úložiště,
•
doplnění této kombinace o rozhraní poskytující funkce jádra prostřednictvím webových služeb
Rozhraní odstíní přístup k datovému úložišti a umožní omezit a zabezpečit přístup k citlivým osobním údajům studentů. Přesto však bude stále schopno poskytnout většinu funkčnosti pro další vzdělávací nebo správní účely. Zásadním přínosem nového projektu bude umožnění spuštění dalšího externího vývoje, tvorby rozšíření nebo nových uživatelských rozhraní pro konkrétní potřeby. Externí vývoj
2
bude moci vznikat bez obav z narušení bezpečnosti systému a narušení osobních údajů zaregistrovaných uživatelů.
1.2. Historie vývoje Historie webové aplikace zasahuje do zimního semestru 2005 / 2006, kde byla poprvé definována a implementována její první verze v rámci předmětu „Datové struktury a algoritmy“, vedeným Ing. Jiřím Chludilem. Aplikaci vyvinul Jiří Hunka.
Obrázek č. 1 Prvotní systém Jagu I – menu (4)
Počáteční požadavky na aplikaci byly poměrně jednoduché, proto v relativně krátké době vznikl první funkční celek pod pracovním názvem „Jagu I“. Vzhled GUI (Graphical User Interface) byl spíše účelový a funkčnost byla značně omezena. Bohužel nebyl brán zřetel na zveřejňování citlivých osobních údajů. Aplikace se nicméně pro své účely dobře osvědčila, a proto se v dalších semestrech dočkala mnoha dalších rozšíření. V druhé verzi, označované pracovně jako „Jagu II", se uvažovalo o rozšíření aplikace i pro potřeby jiných předmětů, než jen pro předmět Datové struktury a algoritmy. Nová verze nabízela mnohá vylepšení a dosahovala větší univerzality. Bylo zavedeno sledování: •
docházky,
•
aktivit na cvičení a
•
evidence bodů za semestrální práci.
Grafické provedení dosahovalo vyšší úrovně, než předchozí verze, ale uživatelsky byla aplikace stále ještě omezená. 3
Na základě zkušeností s obecnou problematikou hodnocení předmětů a zapracování požadavků vedoucího práce vznikl, v rámci bakalářské práce Jiřího Hunky (4), projekt Studentova berlička. Projekt byl implementován na platformě PHP s databází MySQL. V roce 2006 byl spuštěn testovací provoz. Po odladění chyb a úpravě uživatelského rozhraní došlo v následujícím roce k uvedení do plného provozu. V této podobě je aplikace používána do současnosti (22).
Obrázek č. 2 Prvotní systém Jagu I - zadávání hodnot (4)
V roce 2008 byl, opět pod odborným vedením Ing. Jiřího Chludila, sestaven tým, který měl za úkol razantně rozšířit stávající funkčnost aplikace. Rozšiřování funkcionality se mělo zabývat inteligentním generováním testů, automatizací jejich opravy a správy semestrálních prací. Na projektu Studentova berlička postupně začalo spolupracovat více lidí. Proto bylo nutné začít uvažovat nad změnou dosavadní architektury systému, která by umožnila sjednotit funkčnost dílčích rozšiřujících projektů a zároveň umožňovala omezit přístup k citlivým osobním údajům zaregistrovaných uživatelů. Právě touto problematikou se zabývá tato práce.
4
Obrázek č. 3 Současná verze projektu Studentova berlička (5)
1.3 Souběžně vyvíjené projekty Na počátku zimního semestru 2009 dostal nově sestavený tým za úkol navrhnout a implementovat dílčí rozšíření systému, které by pomohlo zefektivnit a zjednodušit administrativu spojenou s písemným zkoušením studentů. V praxi se přednášená látka většinou testuje písemnou formou na cvičeních daného předmětu. Vyučující sestaví na základě odpřednášené látky testové otázky, předloží je studentům na hodině k vypracování, a zbytek svého volného času stráví opravou. Po opravě, v následující hodině cvičení, následuje bouřlivá diskuze a vyjednávání nad počtem bodů a nad správností řešení. Opět ale na úkor času vyměřeného pro další procvičení látky.
5
Obrázek č. 4 Schéma kooperace souběžně vyvíjených projektů
Zjednodušení, zefektivnění a především zautomatizování výše popsaného administrativního úkonu dostaly za úkol dva projekty. První, s názvem „Generátor testů“ (12), by měl pomoci vytvořit a spravovat databázi testových otázek tak, aby si vyučující mohli jednotlivé testy mezi sebou sdílet a navzájem je modifikovat a doplňovat. To by umožňovalo sjednotit a zjednodušit obtížnost tvorby písemných testů nebo umožnit sestavení souhrnných testů, kde by mohl každý z vyučujících zadat jen vlastní odbornou část. Druhý zmíněný projekt (10) by se měl zaobírat zautomatizováním opravy testů. Tedy jejich naskenováním do databáze a následným převodem do elektronické podoby, který zjednoduší jejich opravu.
6
1.3.1 Generátor testů Generátor testů nemohl vzniknout jako samostatná a úplně oddělená aplikace, protože je naprosto nezbytné, aby ukládal informace o vygenerovaných testech a jejich struktuře přímo do datového úložiště projektu Studentova berlička. Důvod toho přístupu je ochrana před nežádoucím únikem připravovaných testů. Jako první byl tímto pověřen kolega Jiří Anděl, který svůj projekt představil ve své bakalářské práci „Studentova Berlička II - Generátor testů“. Kolega Anděl měl za úkol zanalyzovat dosavadní způsob zadávání testů. Na základě analýzy vypracovat externí aplikaci, která by vyučujícímu nabídla kvalitnější uživatelské prostředí. Externí aplikace měla být propojena se Studentovou berličkou pomocí webových služeb. V minulém akademickém roce (2009/2010) navázal na práci Jiřího Anděla, který své zadání nedokončil, kolega František Kraml s tématem „Studentova Berlička III - Generátor testů“ (12).
1.3.2 Automatické vyhodnocení testů Zpracování naskenovaných testů komplikuje strojové čtení ručně psaného textu. Kolega Petr Kotek se ve své bakalářské práci (10) zaměřil pouze na rozpoznání nejdůležitějších údajů v testu. To znamená bodové hodnocení jednotlivých otázek a jména a příjmení studentů. Rozpoznávané údaje měly v testu přesně vyhrazené místo, určené pomocí kalibračních značek, které tiskl společně s otázkami generátor testů. Stejně jako v případě Generátoru testů měla i tato aplikace komunikovat se Studentovou berličkou pomocí webových služeb. Po vyhodnocení testu vyučujícím mělo dojít k automatickému uložení informací do Studentovy berličky. Studenti by pak mohli v reálném čase získávat informace o svém bodovém hodnocení a prohlédnout si kopii své písemné práce. Zároveň měla aplikace nabídnout přehledné a ergonomické uživatelské rozhraní a měla být připravena na budoucí možnost opravy testů jen pomocí tabletu. Kolega Petr Kotek si pro implementaci zvolil jazyk Java, čímž byla prokazatelně doložena funkčnost komunikace mezi systémy s rozdílnou platformou.
7
1.3.3 Centrum služeb Výše uvedené bakalářské práce, vypsané v minulém akademickém roce (2008/2009), měly především otestovat účinnost modulárního vývoje a ověřit funkčnost zvolené technologie pro komunikaci a předávaní dat mezi externími aplikacemi a Studentovou berličkou. Úspěšně byla zdokumentována komunikace mezi aplikacemi postavenými na různých platformách a jednoduché předávání binárních dat. V letošním akademickém roce (2009/2010) vznikl opět nový tým, který navazuje na předchozí práce kolegů a na základě analýzy požadavků na systém má za úkol navrhnout nové datové úložiště a aplikační logiku Studentovy berličky. Datové úložiště si vzal na starost kolega Tomáš Králík (11). Problematika aplikační logiky a její implementace byla nabídnuta kolegovi Jaromírovi Vaňkovi (26). Studentova berlička je odladěný nástroj, který byl již v několika obměnách nasazen do ostrého provozu. Za pomoci výše zmíněných prací kolegů Králíka a Vaňka by měl být položen základ pro nový, pružnější a snadno rozšířitelný systém, který by v budoucnu nahradil současně používanou Studentovu berličku. Aby nedocházelo k nejasnostem v terminologii, dostala práce kolegů Králíka a Vaňka pracovní název „Centrum služeb.“
8
2 Analýza V kapitole o historii popisuji, za jakých okolností vznikl systém Studentova berlička. Monolitická struktura systému není bohužel vhodná pro další rozšiřování své funkčnosti, aplikační logika je pevně svázána s prezentací dat. Krom toho uživatelské rozhraní všem uživatelům ne zcela vyhovovalo. Namísto rekonstrukce stávajícího systému jsme přistoupili k návrhu zcela nové aplikace. Tato nová aplikace by měla být koncipována takovým způsobem, aby ji bylo možné snadno přizpůsobit pro různé účely. Koncept by měl spočívat v jednotném úložišti dat a uvolnění metodiky pro úpravu uživatelského rozhraní, případně možností implementace vlastního GUI, dle svých představ. Cílem této práce je zhodnotit nároky, které budou kladeny na aplikaci, a na základě
těchto
předpokladů
zvolit
nejvhodnější
technologie
a
odpovídající
architekturu, pro vytvoření nového systému.
2.1 Rozbor architektury Architekturou se v oblasti informačních technologií rozumí popis infrastruktury informačního systému. Zahrnuje popis vnitřního uspořádání jednotlivých částí systému, jejich funkčnost a jejich interakci s vnějším okolím. V této části si nejdříve definujeme hodnotící kritéria. Poté si představíme několik používaných architektur informačních systémů a nakonec vybereme tu nejvhodnější pro naše potřeby. Výběr architektury budeme hodnotit především podle těchto vlastností (9): •
Flexibilita
•
Distribuovanost
•
Nezávislost na implementačním prostředí
Flexibilita Nová aplikace by měla být dostatečně flexibilní, aby bylo možné snadno a bez velké režie pozměňovat stávající funkčnost nebo ji dále rozšiřovat.
9
Distribuovanost Distribuovaný systém je takový výpočetní systém, který zahrnuje více než jeden procesor nebo počítač, mající svůj program rozdělený na části. Tyto části si vzájemně předávají data, které jsou zpracovávána na různých spolupracujících procesorech nebo počítačích.(6) Měli bychom do návrhu aplikace zahrnout požadavek, aby mohla aplikace a její jednotlivé části pracovat na různých na sobě nezávislých strojích.
Nezávislost na implementačním prostředí Můžeme předpokládat, že naší aplikaci bude vyvíjet větší počet studentů. Zároveň budou řešit dílčí problémy, pro které pravděpodobně bude vhodné použít rozdílné programovací nástroje a technologie. Při výběru architektury bychom měli zajistit pokud možno co nejlepší spolupráci jednotlivých dílčích rozšiřujících modulů, napsaných v různých programovacích jazycích a pracující pod různými operačními systémy.
2.2 Modely architektur V této kapitole si představíme nejběžněji používané architektury při vývoji informačních systémů: •
Monolitická
•
Dvouvrstvá – Klient-Server
•
Třívrstvá – MVC (Model-View-Controller)
•
Peer-to-peer - Klient-Klient
•
Servisně orientovaná – SOA (Service Oriented Architecture)
10
Monolitická architektura Aplikace s touto architekturou nemá žádné vnitřní uspořádání, nedělí se na žádné logické celky. Celá aplikace je, jak již název napovídá, nedělitelný monolitický blok, běžící na jednom počítači. + Snadná implementace. + Minimální nároky na technické vybavení. - Rozšíření aplikace není možné bez zásahu do celé struktury kódu. - Bez možnosti distribuovanosti. - Silná svázanost s implementačním prostředím.
Dvouvrstvá architektura Dvouvrstvá architektura dělí aplikaci na část klientskou a na část serverovou. Klient představuje uživatelské rozhraní aplikace a poskytuje prezentační služby. Klienty dělíme na tlustý a tenký (7). Tlustý klient kromě uživatelského rozhraní obsahuje i aplikační logiku. V případě tenkého klienta je aplikační logika přesunuta na server. Tenký klient tvoří ve většině případů pouze internetový (webový) prohlížeč, který je dnes již standardní součástí softwarového vybavení běžného počítače (27). Serverová část zajišťuje komunikaci a koordinaci zpracovávaní požadavků klientů. Typicky komunikuje více klientů s jedním serverem. Mimo zpracování požadavků, zajišťuje server především služby spojené s prací nad daty. + Snadná implementace + Distributivita dat + V případě tenkého klienta, nezávislost na běhovém prostředí - Svázanost aplikační logiky s prezentací dat - Svázanost s implementačním prostředím
11
Třívrstvá architektura Architektura označovaná jako MVC (Model View Controller) je rozdělena na tři logické celky, starající se o uživatelské rozhraní (view), aplikační logiku (controller) a datový model (model). Každá komponenta pracuje zcela nezávisle na ostatních. + Oddělení aplikační logiky a prezentace dat. + Opakovaná možnost použití kódu. + Nezávislost komponent. - Svázanost s implementačním prostředím.
Obrázek č. 5 Schéma MVC
Peer-to-peer Peer-to-peer neboli klient–klient představuje architekturu rovnocenných klientských aplikací. V této architektuře není zádná aplikace nadřazená ostatním. Takže zde neexistuje pojem server. Klientské aplikace jsou schopné komunikovat každá s každou a výpočet je plně distribuovaný (17). + Distributivita dat - Architektura nevhodná pro informační systémy
12
Obrázek č. 6 Schéma propojení Klient-Server a Peer-to-Peer
Servisně orientovaná architektura Servisně orientovaná architektura (SOA) umožňuje flexibilně provázat různé aplikace napříč platformami a technologiemi. Každá z propojených aplikací funguje jako nezávislý blok poskytující služby. Každá služba je vybavena přesně popsaným rozhraním. Umožňuje tak ostatním aplikacím, aby skrze něj využívaly její služby (28). + Flexibilita + Nezávislost na platformě + Distributivita dat
Závislost na Flexibilita
Distribuovanost
implementačním prostředí
Náročnost implementace
Technické vybavení
Monolitická
Ne
Ne
Silná
Snadná
Minimální
Dvojvrstvá
Ano
Ano
Střední
Střední
Střední
Třívrstvá
Ano
Ano
Střední
Složitá
Střední
Peer to peer
Ano
Ano
Slabá
Střední
Minimální
SOA
Ano
Ano
Slabá
Střední
Střední
Tabulka č. 1 Přehled vlastností porovnávaných architektur
Předpokládáme, že se náš informační systém, který má nahradit Studentovu berličku, bude vyvíjet postupně a na etapy v rámci několika studentských prací. 13
Architektura by tedy měla být navržena tak, aby bylo možné tyto práce sjednotit v jeden funkční celek. Při výběru vhodné architektury nesmíme zapomenout na fakt, že by neměla být příliš komplikovaná, aby její porozumění studentům nezpůsobovalo zbytečnou zátěž. Z uvedených architektur je pro porozumění nejjednodušší monolitická, celý systém tvoří jeden blok kódu. Takováto architektura je pro větší systém zcela nekoncepční, a proto ji hned z výběru vyřadíme. Stejným způsobem můžeme výběr zúžit o architekturu peer-to-peer, která je vhodná především pro aplikace zabývající se distribuovaným výpočtem, což není případ našeho projektu. Pro účely informačního systému se více hodí použít architekturu, která je založená na principu dotaz / odpověď nad množinou strukturovaných dat. Všechny tři zbývající popisované architektury jsou pro toto vhodné. Dvouvrstvá architektura se od třívrstvé liší, jak je patrné z názvu, o vrstvu, která umožňuje oddělit aplikační logiku od prezentace dat. Třívrstvá architektura je proto mnohem vhodnější a budeme ji preferovat před dvouvrstvou variantou. Do finálního výběru tak postupuje architektura třívrstvá a SOA. Na základě všech uvedených kladů a záporů vybereme pro vývoj Centra služeb architekturu orientovanou na služby. Jako jediná umožňuje propojit, za dodržení určitých postupů, aplikace a moduly napsané v rozdílných programovacích jazycích. Přesto je její struktura méně komplikovaná na porozumění než MVC. Vývojáři jednotlivých modulů navíc nemusí znát strukturu celé aplikace, stačí jim pouze navázat na přesně definované rozhraní. SOA tak nabízí velice flexibilní, moderní a škálovatelný systém, založený na nezávislých modulech, poskytujících si navzájem služby. Ze své podstaty nabízí vytvářet rozdílné prezentace dat, bez jakýchkoliv technických omezení.
14
2.3 Technologie SOA V této představitele
kapitole servisně
si
představíme orientovaných
a
stručně
technologií.
popíšeme
nejvýznamnější
Porovnáme
způsob
a
komplikovanost jejich implementace a jejich dostatečnou podporu v programovacích jazycích. Nakonec vybereme nejvhodnější technologii, která bude použita v nově vzniklé aplikaci, která nahradí Studentovu berličku.
2.3.1 CORBA Standart CORBA vzniká na počátku 90. letech, pro účely sdružení společností OBG1, které tvořili například IBM, HP nebo Sun. V roce 1995 vychází nová verze standartu CORBA 2.0, která byla zakomponována do jazyku Java, což přispělo k dalšímu masivnějšímu rozšíření této architektury. (13)
Obrázek č. 7 Model CORBA (13)
Princip architektury je využívání platformě nezávislých, distribuovaných objektů. Klient přistupuje k dostupným objektům, bez ohledu na to, v jakém jazyce jsou napsány, na jakém počítači běží, či jakým komunikačním protokolem jsou jednotlivé počítače provázány. (13) Každý dostupný objekt je zapouzdřená entita, která poskytuje jasně popsané
1
OMG - Sdružení Object Management Group
15
služby.
Způsob
přístupu
k
službě
distribuovaného
objektu
je
proveden
prostřednictvím zasíláním požadavků. Konkrétní implementace zpracování, odesílání a přijetí požadavků je v každém jazyce odlišná a tedy závisí na jazyku, ve kterém je napsán klient. Ve starších programovacích jazycích je zasílání požadavků provedeno voláním vygenerovaných funkcí (stubs), jazykem popisujícím objekty (IDL). U novějších
programovacích
jazyků,
umožňujících
objektově
orientované
programování, se zasílání provádí voláním zástupných metod distribuovaného objektu.(13) Jazyk IDL (Interface Definition Language) definuje rozhraní distribuovaných objektů. Syntaxe jazyka se podobá C++. Při vývoji aplikací využívajících systému COBRA se nejdříve deklarují distribuované objekty pomocí univerzálního jazyka IDL a následně se příslušným překladačem vygenerují zdrojové kódy pro příslušný programovací jazyk, ve kterém je implementován klient nebo server. Protokol IIOP (Internet Inter ORB Protocol) je síťový protokol, který definuje komunikaci ORB komponent. ORB komponenty mohou mít různou implementaci.
+
Využití služeb objektu nezávisle na platformě.
+
Veřejný IDL popis objektů
-
Komplikovaná implementace
-
Architektura vhodná pouze pro aplikace těžkých klientů
2.3.2 RMI Java
RMI
(Remote Method Invocation) je
technologie
distribuované
komunikace určená pro platformu Java. Umožňuje objektu na jedné JVM (Java Virtual Machine) jednoduše spustit metodu jiného objektu na vzdálené JVM. Při volání vzdálené metody získává klient referenci na vzdálený objekt prostřednictvím jmenné služby poskytované RMI. RMI používá objektovou serializaci pro posílání parametrů metod a návratových hodnot, tj. posílají se objekty, u kterých je možno využít všech jejich vlastností včetně polymorfismu. Vzdálené volání metod má tu samou syntaxi, jako volání metod lokálních objektů. RMI poskytuje podporu pro dynamické stahování kódu. 16
Veškeré třídy, rozhraní, nástroje pro vytvoření a spuštění RMI aplikace jsou součástí J2SE (Java 2 Standard Edition).
Obrázek č. 8 RMI Model (6) +
Snadná implementace
+
Popis parametrů, atributů a návratových hodnot je zařízen automaticky
-
Závislost na platformě Java
2.3.3 XML-RPC XML-RPC (XML-Remote Procedure Call) je první uváděný příklad webové služby. Zkratka RPC označuje, že protokol umožňuje volat procedury na vzdáleném počítači. Druhá zkratka označuje, jakým způsobem protokol dociluje vzájemné komunikace přes připojení HTTP (Hypertext Transfer Protocol) (24). Klient XML-RPC zabalí informace o volané proceduře do dokumentu XML (eXtensible Markup Language). XML zpráva je předána serveru přes normální požadavek POST HTTP. Server zpracuje doručený XML soubor, zavolá patřičnou místní funkci a vrátí (opět přes požadavek HTTP) výsledky v podobě jiného dokumentu XML.
17
+
Snadné využití protokolu HTTP
+
Komunikace přes zasílání zpráv ve formátu XML
+
Platformě nezávislý
+
Podpora v jazyku PHP
-
Nevhodné pro přenos strukturovaných dat
2.3.4 SOAP Jako poslední protokol webové služby si představíme protokol SOAP (Simple Object Access Protokol). SOAP vychází ze specifikace protokolu XML-RPC, přebírá tak i jeho podstatnou výhodu, a to formát přenášených zpráv s jejich nezávislostí na platformě. Navíc ve svém protokolu SOAP zahrnuje všeobecnější rámec pro výměnu strukturovaných informací jakéhokoliv druhu. Na rozdíl od XML-RPC, které umožňuje komunikovat pouze a jen přes HTTP, může SOAP teoreticky běžet přes jakýkoliv přenosový protokol (HTTP, SMTP, FTP a jiné). Další z hlavních rozdílů mezi SOAP a XML-RPC je podpora způsobů, jakými může server vyjmenovat své metody a jejich argumenty. Klient pak může automaticky odhalit metody, které server nabízí, a použít informace o typech argumentů, aby správně naformátoval svůj požadavek (28).
+
Podpora v jazycích ASP, PHP, Java
+
Platformě nezávislý
+
Komunikace zasíláním zpráv ve formátu XML
+
Veřejný WSDL popis služeb
+
Snadná implementace
+
Podpora pro přenos strukturovaných i binárních dat
+
Spolupráce s HTTP, SMTP, FTP
18
2.3.5 REST REST (Representation State Transfer) není formálním standardem, nýbrž stylem architektury rozhraní, navržené pro distribuované prostředí. Pojem REST byl popsán v roce 2000 v disertační práci Roye Fieldinga.(16) REST je, na rozdíl od známějších XML-RPC či SOAP, orientován datově, nikoli procedurálně. Webové služby definují vzdálené procedury a protokol pro jejich volání, REST určuje jak se přistupuje k datům. Rozhraní REST je použitelné pro jednotný a snadný přístup ke zdrojům (resources). Zdrojem mohou být data, stejně jako stavy aplikace (pokud je lze popsat konkrétními daty). Všechny zdroje mají vlastní identifikátor URI a REST definuje čtyři základní metody pro přístup k nim.(16) REST je architektura, která umožňuje přistupovat k datům na určitém místě pomocí standardních metod HTTP, kterými jsou GET, POST, PUT, DELETE a HEAD. Poslední tři přístupy nejsou příliš využívány. Pomocí REST lze ovládat i stav aplikace, pokud jej dokážeme popsat takovým způsobem.(25) Velmi podstatným důvodem nedávného růstu zájmu o REST je jeho snadného použití společně s populárním způsobem návrhu webových aplikací využívajících technologii AJAX (Asynchronous JavaScript and XML). Na rozdíl od XML-RPC nebo SOAP nemá protokol REST v jazyce PHP dostupnou žádnou přímou podporu. Vzhledem k tomu, že REST využívá HTTP požadavky, je možné použít existující síťové funkce pro vytvoření a zpracovaní HTTP požadavku.
+
Snadné propojení s technologií AJAX
+
Přístup k datům přes HTTP
-
Nemá podporu v jazyku PHP
19
Nezávislost
Komunikační
na platformě
protokol
CORBA
Ano
GIOP/IIOP
REST
Ano
HTTP
RMI
Ne
HTTP
SOAP
Ano
HTTP
XML-RPC
Ano
HTTP
Dostupnost
Podpora
Náročnost
v PHP
implementace
Ne
Komplikovaná
Ne
Střední
Ne
Snadná
Ano
Snadná
Ne
Střední
Komerční Open source Open source Open source Open source
Tabulka č. 2 Přehled vlastností dostupných webových služeb
Podle vlastností v tabulce č. 2 můžeme hned na začátku výběru vyloučit CORBA a RMI. CORBA je ze všech popsaných technologií nejsložitější na implementaci a v současné době je již překonaná. Naopak RMI nabízí mnoho pozitiv, bohužel je ale výlučně spjatá s platformou Java. Nesplňuje tak naší základní podmínku implementační nezávislosti na platformě. Výběr se tedy zúžil pouze na technologie REST, SOAP a XML-RPC. REST ani XML-RPC nemá vestavěnou podporu v jazyku PHP. XML-RPC navíc není vhodná pro komplexnější komunikaci mezi systémy. Zbývá nám jediná technologie, která splňuje všechna naše kritéria. Touto technologií je SOAP.
20
3. Implementace Účelem této práce je navrhnout a popsat vhodné technologie pro implementaci nové webové aplikace, jenž zastoupí současně používanou Studentovu berličku. Z analýzy vyplývá, že systém má být postaven na architektuře servisně orientovaných služeb, konkrétně za využití protokolu SOAP. Tato kapitola se bude podrobněji zabývat vysvětlení funkčnosti webových služeb. Dále si rozebereme protokol SOAP a některé další komponenty spojené s webovými službami, jako je popis a registr webových služeb. Závěrem kapitoly si přiblížíme něco málo o zabezpečení aplikací postavených na tomto základu.
3.1 Webové služba Servisně orientovaná architektura je technologie umožňující flexibilně provázat různé nezávislé moduly a aplikace, které poskytují služby. V internetovém prostředí, dostupném přes standardní protokol HTTP, je možné realizovat SOA pomocí tzv. webových služeb. Webové služby představují jeden z technologických prostředků, kterým je možné realizovat principy SOA. (21)
21
3.1.1 Části webové služby Webové služby se skládají ze tří vzájemně interagujících částí. Jsou to poskytovatel služeb, registr služeb a samostatný klient. (15)
Obrázek č. 9 Schéma webové služby •
Poskytovatel služeb – Poskytovatel služeb (Server) je softwarová nebo hardwarová platforma, která zajišťuje provoz vlastních webových služeb.(15) Poskytuje tedy klientům funkce prostřednictvím standardního webového protokolu.
•
Registr služby – Registr (UDDI Registry) služeb je místo, kde jsou uloženy informace o webových službách a jejich poskytovatelích. V registru služeb mohou uživatelé vyhledávat poskytovatele a potřebné informace pro navázání spojení mezi uživatelem a poskytovatelem služeb. (15)
•
Klient – Klient v tomto případě není uživatel, který vyhledává požadovanou funkci v registru služeb. Jedná se o aplikaci, která volá požadavky serveru.
22
3.1.2 Operace webových služeb Pro tři výše uvedené části webových služeb byly definovány operace, které zajistí vzájemnou spolupráci. •
Publikování – Publikování je interakce mezi poskytovatelem služeb a jejich registrem. Zpřístupňuje webovou službu klientům. (15)
•
Vyhledávání – Vyhledávání je komunikace mezi klientem a registrem služeb. Ty dodávají uživateli potřebné informace o poskytovatelích webových služeb a potřebné informace pro navázání spojení. (15)
•
Propojení – Třetí a nejdůležitější operací je Propojení. Propojení je interakce mezi poskytovatelem služeb a uživatelem. Díky ní je možné webovou službu využívat. (15)
23
3.2 Protokol SOAP První verze (1.0) protokolu SOAP vznikla na konci roku 1999 jako výsledek společné práce firem DevelopMentor, Microsoft a UserLand, které chtěly vytvořit protokol pro vzdálené volání procedur (RPC) založený na XML. V průběhu roku 2000 se k podpoře přihlásila i firma IBM, a nová verze SOAP 1.1 byla zaslána W3C Consortium. Verze SOAP 1.1 je dnes nejpoužívanější. Na půdě W3C Consortia nyní probíhá práce na uvolnění prvního skutečného standardu SOAP 1.2 v rámci pracovní skupiny pro XML protokol. (20) Protokol
SOAP
jsme
v analýze
vybrali
na
základě
široké
podpory
v programovacích jazycích a nezávislosti na platformě. Tyto pozitivní vlastnosti vycházejí z principu komunikace mezi klientem a rozhraním webové služby. Protokol SOAP je založen na principu synchronní komunikace typu požadavek – odpověď. Požadavek i odpověď jsou přenášeny po médiu ve formě XML, což je standardizovaný formát pro výměnu informací. Komunikace probíhá takovým způsobem, že klientská aplikace serializuje stávající požadavek na webovou službu do zprávy XML a zašle ji na server. Server tuto zprávu dekóduje, obslouží požadavek a výsledek opět serializuje do XML zprávy, kterou vrátí zpět klientovi.
Struktura zprávy SOAP požadavek / odpověď začíná hlavičkou protokolu, který zprávy přenáší. SOAP není závislý na transportním protokolu, ale nejčastěji využívá protokol HTTP, SMTP nebo FTP. Vlastní SOAP zpráva je uzavřena do XML elementu Envelope. Ten definuje příjemce zprávy, způsob doručení, jmenný prostor a kódování dat. Kořenový element Envelope uzavírá další dva významné elementy, Header a Body, jak je možno vidět na schematickém Obrázek 3. Element Header není pro zprávu povinný, ale umožňuje do zprávy přidat například autentizační údaje nebo informace o transakcích.
24
Obrázek č. 10 Struktura SOAP zprávy
Element Body slouží jako kontejner především pro přenos dat a dalších důležitých informací o volaných službách, předávaných parametrech a návratových hodnotách. Protokol SOAP je vybaven mechanismem identifikace a popisem chyb. Informace o nastalé chybě se ve zprávě přenášejí v elementu Fault, který je také součásti elementu Body
Komponenty webové služby Protokol SOAP je úzce svázán s dalšími dvěma technologiemi. Jsou to WSDL (Web Services Description Language) a registr UDDI (Universal Description, Discovery and Integration). Technologie WSDL je jazyk určený pro popis rozhraní webové služby a registr UDDI slouží jako veřejně přístupný seznam dostupných webových služeb.
Provázání klienta, rozhraní webové služby a registru UDDI schématicky ilustruje Obrázek 2.
Vztah těchto tří technologií si můžeme popsat tak, že po
dokončení vývoje webové služby je vygenerován WSDL popis jejího rozhraní. Tento popis je pak zaregistrován do registru UDDI. Naopak vývoj klienta začíná vyhledáním 25
v registru patřičného WSDL popisu dostupné služby, se kterou hodlá navázat spojení. Na základě informací z popisu rozhraní webové služby se následně přizpůsobí klientská část.
Obrázek 11 Vztah tří základních technologií webových služeb (9)
26
3.3 WSDL WSDL vzniklo jako společná iniciativa firem Microsoft a IBM, které si uvědomily potřebu sjednocení jazyka používaného pro popis rozhraní webových služeb. Navazuje tak na předchozí aktivity, zejména na jazyky NASSL (Network Accessable Service Specification Language), SCL (SOAP Contract Language) a SDL (Service Description Language). WSDL je v současné době vydán jako informativní poznámka W3C a v rámci pracovní skupiny pro popis webových služeb se pracuje na vytvoření skutečného standardu. (9) WSDL je jazyk určený pro popis rozhraní webové služby. Jeden popis vždy popisuje jen jednu službu. WSDL můžeme přirovnat ke staršímu standardu, jazyka IDL, který slouží pro popis rozhraní u technologie CORBA. Na rozdíl od IDL, které se syntakticky
blížilo
k jazyku
C,
tak
WSDL
pro
svoji
reprezentaci
zvolilo
standardizovaný formát XML. Popis rozhraní obsahuje seznam metod poskytovaných serverem, formát jejich vstupních a výstupních parametrů. Především však obsahuje přesné informace o umístění webové služby.
Struktura WSDL Struktura celého dokumentu webové služby se skládá z elementů popisujících umístění služby, způsobu navázaní dat, seznamu poskytovaných metody a seznamu použitých datových typů. Těchto několik významných elementů je zabaleno do kořeného elementu Definition. Konkrétně si tedy přiblížíme elementy Types, Message, Operation, PortType, Binding a Service. • Service – Největší jednotka celého popisu, reprezentuje celou webovou službu. Obsahuje informace o jedné nebo více branách (Port). • Port – Definuje adresu umístění webové služby. Každý z portů má vazbu (Binding). • Binding – Podrobnosti o protokolu pro každý port a pro navázané operace služby pomocí rozhraní (PortType). 27
• PortType – Popisuje sadu abstraktních operací (Operation) pro definici vstupu, výstupu a reakci na chybu. Každá z operací představuje jednu metodu ze seznamu poskytovaných metod webové služby. • Operation – Každá operace většinou definuje dvě zprávy (Message), a to vstupní a výstupní. Vstupní zpráva představuje volání metody poskytované webovou službou. Definuje seznam předávaných parametrů (Types). Výstupní zpráva obsahuje informace o výsledku zpracování vstupní zprávy. Definuje typ (Types) návratové hodnoty. • Message – Zprávy odpovídajících operací. • Types – definuje seznam všech datových typů použitých webovou službou. Definují se podle XML schématu, které obsahuje základní datové typy, jako je textový řetězec, celá i desetinná čísla, binární data, logické hodnoty a datum a čas. Je možné také definovat komplexnější datové typy, složením z několika základních.
Obrázek č. 12 Struktura dokumentu WSDL. 28
3.4 UDDI Registr UDDI je v přeneseném významu jakýsi telefonní seznam všech registrovaných webových služeb. Nabízí nejen informace o registrovaných službách, ale i informace o jejich registrátorech. Standardním vybavením každého registru je pak několik způsobů, jak v tom telefonním seznamu vyhledávat. Umístění webové služby do registru UDDI není podmínkou a nemá žádný vliv na její funkčnost. Paradoxně je registr UDDI svým způsobem také webová služba, která poskytuje informace o jiných službách. Proto je také možné s registrem navázat vzdálené spojení prostřednictvím protokolu SOAP.
Rozdělení UDDI UDDI registr je rozdělen na tři části. Stejně tak, jako se celému registru přeneseně přezdívá telefonní seznam, tak i jeho tři části se přeneseně nazývají Bílé, Zlaté a Zelené stránky. Rozdělení ilustruje následující obrázek (Obrázek č. 11.
Obrázek č. 13 Struktura registru UDDI
29
• Bílé stránky – tento seznam obsahuje informace o registrátorovi webové služby, jako například adresa, kontaktní údaje, obor působnosti registrátora a další upřesňující identifikátory • Zlaté
stránky
–
seznamy
registrovaných
služeb,
seskupené
podle
registrátora. • Zelené stránky – podrobný popis rozhraní webové služby registrátorem. Obsahuje WSDL popis rozhraní registrované webové služby.
3.5 Zabezpečení Předností webových aplikací je jejich snadná dostupnost. Tato výhoda však na druhé straně představuje i velké bezpečnostní riziko. Proto je důležité věnovat tomuto tématu pozornost. V následujících kapitolách si shrneme zabezpečení internetového protokolu a webové služby.
3.5.1 Zabezpečující protokol HTTPS Protokol HTTPS (Hypertext Transfer Protocol Secure) je zabezpečovacím síťovým protokolem, založený na principech síťového protokolu HTTP. Data přenášená přes protokol HTTPS nejsou přenášená jako prostý text, jako je tomu u HTTP, ale jsou šifrována pomocí SSL (Secure Sockets Layer) nebo TLS (Transport Layer Security) (23). Standardním portem na straně serveru bývá 443. (29) Protokol HTTPS využívá asymetrické šifrování, takže server musí vlastnit certifikát. Certifikát je v České republice vydáván a podepisován certifikační autoritou ICA nebo Českou poštou. Nekomerční způsob zajištění certifikátu je možné zařídit tak, že vydavatel si sám sobě certifikát podepíše (self-signed certificate). Self-signed certifikáty vyhodnotí internetový prohlížeč jako nedůvěryhodné a bude před nimi uživatele před varovat. Uživatel musí pro přijetí certifikátu potvrdit, že souhlasí s přidáním veřejného klíče do úložiště webového prohlížeče (příp. úložiště certifikátů operačního systému). Protokol díky svému zabezpečení zaručuje ochranu proti sledování paketů (packet-sniffingu) a sledování komunikace mezi dvěma uzly (man in the middle). 30
Předpokládáme, že zabezpečující protokol HTTPS bude uveden do provozu až po odladění všech nedokonalostí nového systému. Mezitím bude aplikace připojena k databázi smyšlených dat a tak se nebudeme muset obávat úniku citlivých dat. Na téma zabezpečení bude pravděpodobně vypsána samostatná práce.
3.5.2 Zabezpečení webové služby Protokol SOAP, ve své základní specifikaci, bohužel zabezpečení na úrovni zprávy vůbec neřešil. SOAP na věc zabezpečení pohlížel takovým způsobem, že je to věc přenosu a že by ji měl obstarat síťový protokol. Tento
způsob
řešení
problému
byl
zcela
nepostačující,
obzvláště
se vzrůstajícím trendem vývoje aplikací orientovaných na webové služby. Proto byla, na základě standardů W3C (World Wide Web Consortium), navržena rozšiřující specifikace současného protokolu SOAP. WS-Security (Web Services Security), jak byla tato rozšiřující specifikace nazvána, pochází z dílny významných společností jako například IBM, Microsoft, Sun nebo VeriSign. Definuje jakým způsobem použít stávající a dostupné mechanismy pro zabezpečení, jako je například digitální podpis nebo kryptografické zabezpečení XML zpráv. Dále tato specifikace definuje obecný rámec pro zabezpečení (Security Token), kterým je následně rozšířena hlavička SOAP zprávy (14). WS-Security předepisuje jakým způsobem zaručit, aby si SOAP komunikace zachovala důvěryhodnost, nepopiratelnost a integritu.
31
4. Tutoriál Praktická část mé diplomové práce spočívala ve zprostředkování technické podpory mladším kolegům, kteří se zabývali dílčími projekty spojenými s Centrem služeb. S kolegy jsem konzultoval použití architektury orientované na služby, jak po teoretické, tak i po praktické stránce. Proto jsem i tuto práci rozdělil na dvě části. Na část teoretickou (kapitola 3), kde popisuji princip funkce servisně orientovaných technologií a část praktickou (příloha 1), kde na konkrétních příkladech vysvětluji výše popsané techniky. Důvodem pro umístění praktické části mezi přílohy je, aby časté výpisy zdrojových kódů nenarušovali celistvost textu. Kolegové Králík (11) a Vaněk (26), zabývající se datovým úložištěm a aplikační logikou pro Centrum služeb, se rozhodli použít pro implementaci svých částí jazyk PHP, proto pojednává přiložený tutoriál o technologii SOAP v prostředí PHP. I když má SOAP v jazyku PHP výbornou podporu, tak mohu dle vlastních zkušeností potvrdit, že krok k naprogramování první funkční miniaplikace nemusí být jednoduchou a intuitivní záležitostí. Při studii vhodných pokladů, a to jak v knižní tak i elektronické verzi, jsem se setkával s kvalitními teoretickými výklady principů funkcionality, doplněné o množství XML výpisů komunikace. Bohužel jsem však postrádal praktické ukázky základní práce vhodné pro vývojáře začínající s touto technologií. Proto je tutoriál postaven na jednoduchých příkladech, které jsou postupně rozšiřovány o složitější prvky. Tutoriál začíná všeobecnými pravidly, které je vhodné dodržovat, aby se předešlo zbytečným chybám při navázání komunikace. Dále následuje přehled tříd, které jsou spojené s protokolem SOAP. Ty nejdůležitější jsou pak rozebrány podrobněji. Jedná se zejména o třídy určené pro návrh klienta a serveru. Zároveň je při jejich použití názorně ukázáno, jak se generuje a pracuje s WSDL popisem rozhraní webové služby. PHP nemá nativní podporu pro generování WSDL popisu, proto je také tutoriál doplněn o popis skriptu, který tuto činnost zajišťuje. Tento skript je uložen s ostatními zdrojovými soubory všech uvedených příkladů na přiloženém CD. Na závěr je uvedeno, jak se pracuje s uživatelsky definovanými datovými typy a jak stahovat nebo ukládat na server data prostřednictvím protokolu SOAP.
32
5. Závěr Tato práce je pouhým začátkem dlouholetého vývoje. Nová aplikace se bude průběžně rozvíjet a testovat v dalších semestrech. Teprve až po otestování a odstranění nalezených vad a nedostatků se nový systém nasadí do ostrého provozu. Za tímto procesem se ještě bude skrývat velký rozsah práce, na kterém se postupně vystřídají další skupiny vývojářů a testerů. V letošním roce jsme, započetím této práce, uzavřeli kapitolu jednoúčelové aplikace Studentova berlička a vydali se novým směrem k vytvoření propracovanější aplikace, která bude snadno spravovatelná a rozšiřitelná. Navíc bude dbát na ochranu citlivých osobních údajů. Součástí zadání této práce byla i implementace webového rozhraní, které se mělo závěrem letního semestru otestovat s paralelně vyvíjenou externí aplikací pro generování testů (12). Bohužel se nakonec, na základě pokynů vedoucího práce, vývoj modulu pro generování testů zaměřil spíše na rozšíření své lokální funkčnosti. K obohacení tohoto modulu o schopnost vzdálené komunikace do současné doby tedy nedošlo. Z těchto důvodů není možné závěrem této práce prezentovat funkční model komunikace. Podle současného plánu by modul s generátorem testů měl být dokončen během letních prázdnin. V nadcházejícím zimním semestru (2010/2011) by pak měl být uveden do provozu. Ostatní moduly ještě vyžadují před vlastním nasazením přepracování. Na základě těchto skutečností byla oproti původnímu plánu implementační část této práce pojata jako tutoriál, který je připojen jako příloha a jeho doprovodné zdrojové soubory jsou uloženy na CD.
5.1 Navazující práce Po úspěšném nasazení jádra s aplikační logikou a webového rozhraní, založeného na technologii SOAP, popsaného v této práci, bych pro další vývoj doporučil zadání několika navazujících projektů. Jednalo by se o práce zaměřené na: • monitoring jádra a rozhraní, a to jak z bezpečnostního, tak i z uživatelského hlediska, • administrační rozhraní pro jádro a datové úložiště, • projekt zabývající se výhradně zabezpečením a kryptografií, a to nejen 33
komunikace, ale i celé aplikace, které by se ztotožňovalo s politikou zabezpečení FIT • projekt spolupracující přímo s jádrem, respektive s datovým úložištěm, který by zajistil propojení datových úložišť Centra služeb a univerzitní komponentou KOS.
5.2 Týmová spolupráce Zásadní zkušeností, kterou jsem získal na tomto projektu, bylo především jednáním a práce s kolegy v týmu. Projektům spojeným se Studentovou berličkou jsem se věnoval nepřetržitě po celou dobu magisterského studia. Seznámil jsem se s moderními technologiemi webový služeb, vyzkoušel jsem si jejich implementaci a další jejich vlastnosti. Tyto nabyté zkušenosti jsem pak předával svým mladším kolegům, které jsem vedl. Pevně věřím, že projekt Centrum služeb, navazující na Studentovu berličku, brzy dosáhne svých cílů a povede ke zlepšení a zefektivnění výuky.
34
6. Použité zkratky, vysvětlení pojmů •
Ajax ( Asynchronoust JavaScript and XML ) - technologie vývoje interaktivních webových aplikací.
•
CORBA ( Common Object Request Broker Architecture ) - Standard CORBA je určen pro tvorbu distribuovaných objektově orientovaných aplikací.
•
ČVUT- České vysoké učení technické v Praze.
•
FEL - Fakulta elektrotechnická.
•
FIT – Fakulta informačních technologií
•
GUI ( Graphical User Interface ) - grafické uživatelské rozhraní. Grafické prostředí webového systému.
•
HTML
( HyperText Markup Language ) - značkovací jazyk pro tvorbu
webových stránek. •
HTTP ( Hyper Text Transfer Protokol ) - internetový protokol vytvořený původně pro výměnu hypertextových dokumentů ve formátu HTML. V současné době je používán i pro přenos dalších informací.
•
HTTPS - nadstavba internetového protokolu HTTP, která poskytuje zvýšenou bezpečnost před odposloucháním či podvržením dat.
•
IDL ( Interface Description Language ) - jazyk určený pro popis rozhraní distribuovaných objektů, využitém systému COBRA.
•
IIOP ( Internet Inter-ORB Protocol ) - síťový protokol , který definuje komunikaci ORB komponent, využívaných v systému CORBA.
•
JVM ( Java Virtual Machine ) - sada počítačových programů a datových struktur, která využívá modul virtuálního stroje ke spuštění dalších počítačových programů a skriptů vytvořených v jazyce Java.
•
MVC ( Model View Controler ) - softwarová architektura.
•
MySQL - multiplatformní datové úložiště. Komunikace probíhá pomocí jazyka SQL.
•
PHP ( Hypertext Preprocesor ) - Skriptovací programovací jazyk pro tvorbu dynamických webových stránek.
•
REST (Representational State Transfer) - architektura rozhraní, navržená pro distribuované prostředí.
•
RMI ( Remote Method Invocation ) – model vzdálených objektů v jazyku Java. 35
•
RPC ( Remote Procedure Call ) – technologie volání procedur, které můžou být uloženy na jiném místě než je umístěn sám volající program
W3C (World Wide Web Consortium) - mezinárodní konsorcium, jehož členové společně s veřejností vyvíjejí webové standardy pro World Wide Web.
•
WSDL ( Web Servisce Description Language ) – jazyk pro popis webové služby.
•
WS-Security ( Web Services Security ) – zabezpečující rozšíření webové služby.
•
XML (eXtensible Markup Language) – obecný značkovací jazyk.
36
7. Obsah CD / |
readme.txt
- soubor se základními informacemi o CD
| -- Text |
Diplomova_prace_Ludek_Chmurovsky.pdf
|
Diplomova_prace_Ludek_Chmurovsky.doc
| | -- Zdrojové soubory | | -- Priklad_1
– Základní režim
| -- Priklad_2
– Výpis XML komunikace
| -- Priklad_3
– Obsluzna trida
| -- Priklad_4
– WSDL režim
| -- Priklad_5
– Uživatelky definovaný datový typ
| -- Priklad_6
– Přenos binárních dat
37
38
8.Použitá literatura [1]. BRAIN E, Travis. XML a SOAP Programování serverů BizTalkTM. 1. vyd. Computer Press, 2000.ISBN 80-7226-303-X [2]. FIŠER, Jakub. Bakalářská práce Studentova Berlička II – management semestrálních prací, 2009. [3]. HTTPS. Wikipedia.org [on-line] Dostupný z WWW: . [4]. HUNKA, Jiří. Diplomová práce Studentova Berlička, 2010 [5]. HUNKA, Jiří. Bakalářská práce Studentova Berlička, 2007 [6]. JANEČEK, Jan. Skripta ČVUT - FEL Distribuované systémy, 2000 [7]. Klient - server. Wikipedia.org [on-line]. Dostupný z WWW: . [8]. KOSEK,Jiří. PHP a XML. 1. vyd. Grada Publishing, a.s., 2009. ISBN 978-80-247-1116-4 [9]. KOSEK, Jiří. Inteligentní podpora navigace na WWW [on-line]. Dostupný z WWW: . [10]. KOTEK, Petr. Bakalářská práce Studentova Berlička II – automatické vyhodnocování testů, 2009. [11]. KRÁLÍK, Tomáš. Bakalářská práce Studentova Berlička III – databáze nezávislého jádra, 2010. [12]. KRAML, František. Bakalářská práce Studentova Berlička III – generátor testů a písemek, 2010. [13]. LAMPA, Petr. CORBA a IIOP [on-line]. Dostupný z WWW: . [14]. LASOŇ, Martin. Zabezpečení webových služeb [on-line]. Dostupný z WWW: . [15]. LEŠTINA, Petr. Zaostřeno na web services - Jak fungují? [on-line]. Dostupný z WWW: . 39
[16]. MALÝ, Martin. REST: architektura pro webové API. [on-line]. Dostupný z WWW: . [17]. Peer-to-Peer. Wikipedia.org .[on-line]. Dostupný z WWW: [18]. SACHA, Marek. Bakalářská práce Studentova Berlička II - podpora zásuvných modulů, 2009. [19]. Secure Sockets Layer. Wikipedia.org [on-line]. Dostupný z WWW: . [20]. Simple Object Access Protocol. Wikipedia.org [on-line] Dostupný z WWW: . [21]. ŠTUMPF, Jindřich. Webové služby a XML [on-line]. Dostupný z WWW: . [22]. Studentova berlička. Webové rozhraní informačního systému. Dostupný z WWW: . [23]. Transport Layer Security. Wikipedia.org [on-line]. Dostupný z WWW: . [24]. SKLAR, David. PHP 5 – moduly, rozšíření a akcelerátory. 1. vyd. Zoner software, 2005.ISBN 80-86815-19-6 [25]. SHU-WAI Chow. Programujeme Mashup aplikace pro Web 2.0 v PHP. 1. vyd. Computer Press, 2008. ISBN 978-80-251-2957-6 [26]. VANĚK, Jaromír. Bakalářská práce Studentova Berlička III – jádro aplikace, 2010. [27]. Vícevrstvá architektura: tenký, tlustý a chytrý klient [on-line]. Dostupný z WWW: . [28]. WOLTER, Roger. Základy xml webových služeb [on-line]. Dostupný z WWW: . [29]. Zabezpečující protokol HTTPS [on-line]. Dostupný z WWW: .
40
Příloha 1- Tutoriál V tomto tutoriálu si postupně ukážeme praktickou implementaci webové služby SOAP v prostředí PHP. Nejprve si probereme nejzákladnější konstrukci klienta a serveru a ukážeme si, jakým způsobem se mezi nimi naváže spojení a jak si předat data. Dále si uvedené příklady rozšíříme o využití služeb jazyka WSDL. Jednotlivé příklady jsou doplněny ukázkami kódu a obrazovkami s grafickým výstupem. Kompletní příklady naleznete na přiloženém CD.
Kódovaní Při navazování komunikace je možné narazit na problém s kódováním dat. Řetězce dat obsahující diakritiku, příp. jiné nestandardní znaky, mohou způsobovat chyby v SOAP komunikaci. Abychom se tohoto problému vyvarovali, je nutné použít na všech vrstvách aplikace shodné kódování. Použijeme tedy kódování UTF-8, které je univerzální a podporuje většinu jazyků. Platí to pro datové úložiště, HTML, PHP, ASPX skripty, dokonce i pro nastavení některých vývojářských nástrojů.
41
SOAP v PHP Technologie SOAP byla vybrána z mnoha dalších odlišných způsobů vzdálené komunikace z důvodu, že pro ni nalezneme v jazyku PHP 5 vestavěnou podporu. Rozhraní (interface) se stejnojmenným názvem SOAP umožňuje velice jednoduše a přehledně vytvářet klientské i serverové části webových služeb. Dokonale odstíní složité zpracovávání (parsování) XML zpráv nebo vytváření soketů pro navázání komunikace se serverem.(3)
PHP třída SoapClient SoapServer SoapFault
Popis Třída SoapClient poskytuje klienta pro verze SOAP 1.1 a SOAP 1.2. Instance je schopná pracovat ve dvou režimech. Režim WSDL a režim ne-WSDL. Třída SoapServer poskytuje server pro verze SOAP 1.1 a SOAP 1.2. Může být použit s nebo bez služby WSDL popisu. Třída SoapFault poskytuje hlášení o chybách při zpracovávání požadavků.
SoapHeader
Třída SoapHeader poskytuje možnost vložení směrovací dat do hlaviček zpráv.
SoapParam
Třída SoapParam reprezentuje předávané parametry v SOAP službách.
SoapVar
Třída SoapVar reprezentuje proměnné nebo objekty v SOAP službách.
Tabulka č. 1 Seznam a popis tříd webové služby SOAP v PHP. (4)
42
Třída SoapClient Třída SoapClient poskytuje několik málo metod, které jsou uvedeny v následující tabulce. U Každé z metod je uvedený popis funkčnosti a formální zápis. Metoda call
Popis Volání SOAP funkce. public mixed SoapClient::__call ( string $function_name , string $arguments )
getFunctions
Vrátí seznam dostupných SOAP funkcí, popsaných jazykem WSDL. Tuto funkci je možné použít jen ve WSDL režimu. public array SoapClient::__getFunctions ( void )
getLastRequest
Vrací poslední SOAP požadavek ve formátu XML. Tuto metodu je možné použít jen za předpokladu, že instance třídy SoapClient byla vytvořena s parametrem options 'trace' => 1
Vrací poslední SOAP hlavičku požadavku ve formátu XML. Tuto metodu je možné použít jen za předpokladu, že instance třídy SoapClient byla vytvořena s parametrem options 'trace' => 1
Vrací poslední SOAP odpověď ve formátu XML. Tuto metodu je možné použít jen za předpokladu, že instance třídy SoapClient byla vytvořena s parametrem options 'trace' => 1 public string SoapClient::__getLastResponse ( void )
getLastResponseHeaders
Vrací poslední SOAP hlavičku odpověď ve formátu XML. Tuto metodu je možné použít jen za předpokladu, že instance třídy SoapClient byla vytvořena s parametrem options 'trace' => 1. public string SoapClient::__getLastResponseHeaders (void )
getTypes
Vrátí seznam použitých datových typů popsaných jazykem WSDL. Tuto funkci je možné použít jen ve WSDL režimu. public array SoapClient::__getTypes ( void )
Definuje cookie, které bude odesláno spolu s požadavkem SOAP.
Explicitně nastavuje umístění webové služby. Ekvivalentní nastavení umístění webové služby je možno zadat v konstruktoru instance SoapClient. public string SoapClient::__setLocation ([ string $new_location ] )
setSoapHeaders
Nastavuje pole objektů SoapHeader, které budou vkládány do hlavičky zpráv. public bool SoapClient::__setSoapHeaders ([ mixed $soapheaders ] )
Tabulka č. 2 Seznam a popis metod třídy SoapClient. (4) 43
WSDL re im Některé metody z uvedeného seznamu v tabulce č.2 vyžadují parametr WSDL. WSDL popis je XML dokument přesně definované struktury2. Ačkoliv nalezneme ve standardních knihovnách jazyka PHP třídy pro práci s XML dokumenty, tak podpora pro generování WSDL popisu webové služby zde bohužel chybí. Pokud chceme provozovat webovou službu s tímto popisem, tak si jednak můžeme XML dokument sestavit staticky, dle pravidel W3C3. Tento způsob je však samozřejmě nepružný ke změnám v poskytovaných metodách. Nebo je možné využít služeb některých PHP frameworků zaměřených na webové služby.
Konstruktor Jako první si pozornost zaslouží konstruktor třídy. Konstruktor může být použit pro vytvoření instance, která bude pracovat v režimu WSDL nebo v režimu neWSDL. V režimu WSDL je do konstruktoru zadán parametr s adresou WSDL popisu vzdálené webové služby, se kterou chceme, aby klient navázal spojení. Instance klienta si automaticky zjistí, jaké služby server nabízí, jaké parametry jsou potřeba a jakých jsou datových typů. V režimu ne-WSDL se hodnota parametru s adresou WSDL popisu nahradí hodnotou null a specifikuje se pouze parametr s umístěním vzdálené webové služby. Jak je patrné, tak režim WSDL je mnohem automatizovanější. Je vhodnější pro složitější webové služby. Ne-WSDL režim se zpravidla vyskytuje u jednodušších služeb, kde by bylo zbytečné programovat službu pro WSDL popis. Výhoda tohoto režimu spočívá i v menší komunikační režii spojené se zpracováním (parsováním) WSDL dokumentu. Příklad č. 1 ukazuje vytvoření instancí klienta pro oba režimy použití WSDL. Úplný seznam možných parametrů konstruktoru lze nalézt v manuálu PHP4.
"http://www.plugin.jagu.cz/Demo/Priklad_1/server.php",'uri' => "ClientPart")); /* * Konstruktor pro ne-WSDL režim */ $client = new SoapClient(null, array('location' => "http://www.plugin.jagu.cz/Demo/Priklad_1/server.php", 'uri' => "ClientPart")); ?> Příklad č. 1 Konstruktor třídy SoapClient (Priklad_1).
Získání informací o serverové webové službě V předchozím odstavci jsme si vysvětili, v jakých režimech může být vytvořena instance třídy SoapClient. Nyní se budeme věnovat dalším metodám, které poskytuje třída SoapClient. Následující metody vyžadují, pro korektní funkčnost, výhradně režim s WSDL popisem. Jsou to metody getFunctions a getTypes. Vrací seznam metod poskytovaných serverem a popis všech používaných parametrů. Je tak možné si automaticky vygenerovat klientské zdrojové soubory s hlavičkami dostupných metod, bez obav z nesprávně uvedených metod nebo jejich parametrů. __getFunctions()); /* Ukázka výpisu použitých parametrů */ var_dump($client->__getTypes()); ?> Příklad č. 2 Výpis metod serveru a použitých parametrů (Priklad_2) .(4)
45
Seznam předdefinovaných konstant5 pro rozšíření jazyka PHP a standardních datových typů6 je dostupný v PHP manuálu. Velice důležité je na tomto místě upozornit na fakt, že jazyk PHP není striktně typový (není potřebné deklarovat datový typ každé definované proměnné). Je však nutné si uvědomit, že k námi implementovanému serveru mohou přistupovat i klienti vystavění v jiných jazycích nebo naopak.
Volání a použití metod webové služby Volání metod webové služby je velmi snadné. Metody serveru voláme stejným způsobem, jako by se jednalo o metody třídy SoapClient.(2) Jak získat informace o poskytovaných službách, včetně jejich parametrů, jsme si ukázali v minulé kapitole na příkladu 2. Příklad použití volání vzdálené metody si názorně ukážeme na dalším příkladě. Předpokládejme, že naše webová služba poskytuje jednu metodu getDatum, která vrací textovou informaci o aktuálním času a datu. V našem příkladě umístíme na webovou stránku jedno pole input (obrázek č.1) a načteme do něj řetězec s datem a časem, který nám poskytne vzdálená metoda getDatum. Začneme konstrukcí instance třídy SoapClient, v níž zadáme potřebné parametry s umístěním webové služby. Vzdálenou metodu pak zavoláme standardním způsobem $client->getDatum(). "http://www.plugin.jagu.cz/Demo/Priklad_1/server.php", 'uri' => "ClientPart"));
/* * Volani vdálené metody getDatum */ echo "getDatum()."\">"; ?> Příklad č. 3 Volání vzdálené metody (Priklad_1).
Zobrazení komunikace Poslední skupinou metod, které poskytuje třída SoapClient, jsou metody umožňující nahlédnout do výměny XML zpráv mezi klientem a serverem. Jsou to metody getLastRequest a getLastResponse. Obě metody vrací poslední XML zprávu s požadavkem klienta, respektive s odpovědí serveru. Je tak možné si ověřit skutečná data předávaná mezi klientem a serverem, a lépe tak pochopit princip funkčnosti webové služby SOAP. Ukázku, v jakém tvaru vracejí tyto metody XML zprávy, je možné vidět na obr. 2. Úplný výpis požadavku od klienta a odpovědi ze serveru je uveden v příkladu 4, resp. 5.
47
Obrázek č. 2 Zobrazení SOAP komunikace (Priklad_3)
<SOAP-ENV:Envelope .... > <SOAP-ENV:Body> <ns1:getDatum/> Příklad č. 4. - Výpis XML zprávy posledního požadavku klientskou metodou getLastRequest
<SOAP-ENV:Envelope .... > <SOAP-ENV:Body> <ns1:getDatumResponse> 29/10/2010 22:51:04 Příklad č. 5. - Výpis XML zprávy poslední odpovědi klientskou metodou getLastResponse
48
Třída SoapServer Třída SoapServer poskytuje o něco méně metod. Jejich názvy, stručný popis a formální zápis jsou uvedeny v následující tabulce. Postupně si v této kapitole ukážeme, jak si vytvořit vlastní server webové služby a popíšeme si, jak pro naši službu vytvořit a zveřejnit WSDL popis. Metoda
Popis
addFunction
Přidá jednu nebo více funkcí k registru SOAP funkcí. public void SoapServer::addFunction ( mixed $functions )
addSoapHeader
Přidá hlavičku, která bude vkládána do odpovídajících zpráv. SoapServer::addSoapHeader ( SoapHeader $object ) Odešle klientovi s aktuálním požadavkem odpověď označující chybu.
Tabulka č. 3 Seznam a popis metod třídy SoapClient. (3)
49
Konstruktor Vytvo ení serveru webové slu by je podobně snadné jako u klienta. Stejně jako u konstruktoru t ídy SoapClient, tak i u konstruktoru serveru si m
eme vybrat
práci v jednom ze dvou re im . Buďto s WDSL popisem, pak do konstruktoru stačí uvést jen adresu WSDL popisu. V opačném p ípadě, kdy k na í slu bě nepot ebujeme WSDL popis, vyplníme do parametru pro adresu WSDL hodnotu null. V tom p ípadě musíme konstruktor doplnit minimálně o parametr uri, uri který definuje jmenný prostor (namespace) serveru. "ServerPart")); ?> Příklad č. 6 Konstruktor třídy SoapServer
Registrování metod do webové slu by Primární funkcí ka dého serveru webové slu by je poskytování svých metod. V této kapitole si popí eme dva zp soby, jak je mo né zaregistrovat na e metody jednotlivě s vyu itím funkce addFunction, pop ípadě jak registrovat rovnou celou skupinu metod obalených do jedné t ídy. Pro tyto účely má roz í ení jazyka PHP k dispozici metodu addClass. V prvním ukázkovém p íkladě č. 7 si vytvo íme jednoduchou webovou slu bu, která bude poskytovat t i metody. P íklad začíná kódem poskytovaných funkcí, následuje vytvo ení instance t ídy SoapServer. Postupně zaregistrujeme jména funkcí do webové slu by a nakonec ná 50
p íklad zakončíme obslu nou metodou
handle. handle Po spu tění serverového skriptu se program zastaví na metodě handle, handle která čeká na obslou ení p íchozích SOAP po adavk . Ná
první ukázkový p íklad si trochu pozměníme a uká eme si, jak
zaregistrovat rovnou celou t ídu s metodami, které poskytuje (p íklad č 8). Poskytované metody nejprve p esuneme do nově vytvo ené t ídy MyClass. MyClass Tuto t ídu pak zaregistrujeme pomocí metody setClass. "ServerPart")); /* * Zaregistrování metod, poskytovaných serverem */ $server->addFunction("getDatum"); $server->addFunction("foo_1"); $server->addFunction("foo_2"); /* * Obsloužení požadavků */ $server->handle(); ?> Příklad č. 7 Zaregistrování metod serveru.
51
"ServerPart")); /* * Registrace třídy s poskytivanými metodami */ $server->setClass("MyClass"); /* * Obsloužení požadavků */ $server->handle(); ?> Příklad č. 8 Zaregistrování metod serveru (Priklad_3)
52
WSDL generátor Na přiloženém CD, v sekci související s tímto tutoriálem, nalezneme skupinu tříd, která je schopná velice snadně vygenerovat WSDL popis. Zaručuje stálou aktuálnost WSDL popisu. Generování se provádí zcela automaticky, a proto dokáže velice pružně reagovat na jakoukoliv změnu v poskytovaných metodách serverem. Než přistoupíme k popisu funkčnosti přiloženého WSDL generátoru, je důležité věnovat trochu pozornosti správnému nastavění konfiguračních souborů serveru tak, aby nedocházelo k ukládání WSDL popisu do vyrovnávacích pamětí. Přiložený WSDL generátor je implementovaný v jazyku PHP, z čehož plyne výhoda, že generátor může být nahrán na webový server a zajišťovat stálou aktuálnost WSDL popisu webové služby. Generátor sestavuje popis registrované třídy na základě lexikografické analýzy anotací, uvedených v komentáři poskytovaných metod. Pro správnou funkčnost generátoru je tedy naprosto nutné dodržet přesný formát komentářů. Ukázka správně okomentované třídy je uvedena v následujícím příkladě (příklad č. 9). Komentář začíná stručným popisem funkčnosti metody, následuje jeden prázdný řádek. Pod prázdným řádkem by měl následovat výčet všech parametrů komentované metody, a to v přesném pořadí, v jakém jsou uvedeny v deklaraci metody. Jako poslední v pořadí se uvádí popis a typ návratové hodnoty.
53
Příklad č. 9 Ukázka nastavení parametrů v souboru wsdl.php . Na příkladě č. 9 jsme si ukázali, jaké zásady psaní kódu je nutné dodržet při použití přiloženého WSDL generátoru. Konečně se dostáváme přímo ke skriptu7, který přímo do okna prohlížeče vypíše popis naší webové služby. Příklad č. 10, který následuje, ukazuje strukturu přiloženého souboru wsdl.php. Tento skript slouží jako rozhraní generátoru. V tomto souboru se postupně nastaví cesta k registrované třídě s poskytovanými metodami, jmenný prostor a nakonec cesta k serverovému skriptu. Další přiložené soubory není potřeba pozměňovat.
7
wsdl.php
54
setDefinitionName("myDefinitionName"); /* * Nastavení cesty k třídě, ze které se generuje popis. * Soap server registruje pouze jednu třídu, proto i wsdl popis * se generuje jen z jedné třídy */ $def->setClassFileName("businessTier/MyClass.php"); $def->setWsdlFileName("myWsdlFileName.wsdl"); $def->setNameSpace("myNamespace"); /* * Nastavení cesty k souboru s registrující webovou službu */ $def->setEndPoint ("http://plugin.jagu.cz/Demo/Priklad_5/server.php"); /* * Výpis XML popisu */ $wsdl = new WsdlWriter($def); print $wsdl->classToWsdl(); ?>
Příklad č. 10 Ukázka nastavení parametrů v souboru wsdl.php (Priklad_5).
Příklad 11 Kompletní výpis WSDL popisu webové služby (Priklad_5)
57
Praktické příklady na závěr Popsali jsme si dvě základní třídy pro implementaci jednoduché webové služby v jazyku PHP. Princip a funkci jednotlivých částí tutoriálu jsme si stále popisovali na co možná nejjednodušším příkladě, který jsme postupně obměňovali a doplňovali. Technologie SOAP byla vybrána především pro svou schopnost snadno pracovat s komplexnějšími daty, než jen s pouhým textovým řetězcem. V této kapitole si proto ukážeme, jak webovou službou zaregistrovat vlastní datové objekty nebo jak pracovat s přenosem souborů.
Přenos strukturovaných dat V následujících několika odstavcích tohoto tutoriálu si prakticky ukážeme, jak mezi klientem a severem zaregistrovat a přenést vlastní objekt. Objekt slouží pouze jako obálka pro naše data. Není schopný poskytovat žádné vlastní metody, jako je tomu například u technologie CORBA. Objekt s daty se před přenosem změní do podoby XML dokumentu (tzv. serializace). Poté se v podobě XML přenese a na druhé straně komunikace se pomocí zpětného procesu (tzv. deserializace) vytvoří identická kopie původního objektu, která se naplní daty z XML odpovědi. Z tohoto důvodu není možné přenést mezi serverem a klientem žádnou aplikační logiku. Jako první začneme s implementací vlastního objektu (příklad č. 12). Implementace vlastního objektu se řídí standardním postupem a zvyklostem v jazyku PHP, pouze nesmíme opomenout konvenci pro psaní komentářů, ze kterých se posléze sestavuje WSDL popis objektu. Nás ukázkový objekt pojmenujeme „User" a vložíme do něj několik veřejných proměnných tak, jak je uvedeno v následujícím výpisu kódu (příklad č. 12).
58
Příklad 12 Objekt User – deklarace (Priklad_4).
Po vytvoření třídy User ji připojíme přímo k registrované třídě MyClass, kterou jsme si představili v minulých kapitolách. Bez připojení by nevznikl kompletní WSDL popis a klientská aplikace by nerozpoznala náš nový datový typ. Následující výpis (příklad č. 13) nám ukazuje metodu poskytovanou serverem, jež vytvoří instanci našeho objektu, naplní jej testovacími daty a vrátí jej klientovi. Upozornil bych na klíčové komentářové slovo @internal, které našemu WSDL generátoru říká, že má provázat návratový datový typ User s předchozím popisem (příklad č. 12). . firstname = "Jan"; $user->surname = "Novak"; $user->id = "12345"; $user->username = "novakj1"; return $user; } ?> Příklad 13 Serverová část - Metoda poskytující objekt User (Priklad_5). 59
Klientská aplikace (příklad č. 14) zavolá vzdálenou metodu getUser, která ji vrátí náš objekt User. Pak se již k datům přistupuje podle stejných pravidel a zvyklostí, jakoby se jednalo o místní instanci objektu. V ukázce kódu (příklad č. 14) se data vypíší na obrazovku a tím si vizuálně potvrdíme funkčnost přenosu. getUser(); echo echo echo echo ?>
Příklad 14 Serverová část - Metoda poskytující objekt User (Priklad_5) Jak jsme se mohli přesvědčit, tak přenos strukturovaných dat mezi naší aplikací a webovou službou se příliš neliší od standardního předávání instancí objektů. Jen nesmíme zapomenout, že objekt není schopen přenést žádnou aplikační logiku. Uvedený příklad je pro účely pochopení principu velmi triviální. Stejným způsobem je však možné vytvářet zapouzdřené objekty, a stejně tak je možné přenášet více objektů najednou. Je také možné deklarovat a předávat celé pole objektů.
60
Přenos binárních dat Na závěr si ukážeme, jak přenést mezi serverem a klientem binární data. V našem případě se bude jednat o archiv dat zabalených pomocí archivačního nástroje zip. Aby bylo možné archiv nebo jakýkoliv jiný soubor přenést XML zprávou, je nutné překonvertovat data do formátu Base64. Formát Base64 je datový formát zobrazující binární data pomocí tisknutelných znaků ASCII (2). V prostředí jazyka PHP převádějí
do a z toho formátu metody base64_encode8 a base64_decode 9. Následující ukázka
(příklad č. 15) představuje jednoduchou metodu
poskytovanou serverem, ve které se za pomocí standardních knihoven PHP pro práci se soubory načte místní archiv „Logo.zip“. Archiv je následně převeden na řetězec ASCII znaků, které vrací naše metoda getDoc. Base64 $encodedData = base64_encode($data); // Uzavření souboru fclose($fp); return $encodedData; } ?> Příklad 15 Ukázka kódu serverové části - přenos archivu zip (Priklad_6)
Ukázku naší klientské části opět začínáme instancí třídy SoapClient. Potřebné parametry, jako adresa webové služby a adresa WSDL popisu jsou pro přehlednost z ukázky vypuštěny. Postup získání dat od serveru je naprosto identický, jako pro práci s řetězcem dat. Vzdálená metoda getDoc nám vrátí řetězec ASCII znaků, které opět dekódujeme na data. Převedená data uložíme do souboru za pomocí standardních nástrojů pro práci se soubory. getDoc(); // Base64-> data $decodedData = base64_decode($data); // Unikátní název souboru $filename = Time().".zip"; // Otevření souboru pro zápis $soubor = fopen($filename, "a+"); // Zápis dat fwrite($soubor, $decodedData); // Uzavření souboru fclose($soubor); ?> Příklad 16 Ukázka kódu klientské části - přenos archivu zip (Priklad_6).
62
Použitá literatura [1]. BRAIN E, Travis. XML a SOAP Programování serverů BizTalkTM. 1. vyd. Computer Press, 2000.ISBN 80-7226-303-X [2]. Base64. Wikipedia. [on-line] Dostupný z WWW: [3]. KOSEK,Jiří. PHP a XML. 1. vyd. Grada Publishing, a.s., 2009. ISBN 978-80-247-1116-4 [4]. Manuál PHP. [on-line] Dostupný z WWW: . [5]. SHU-WAI Chow. Programujeme Mashup aplikace pro Web 2.0 v PHP. 1. vyd. Computer Press, 2008. ISBN 978-80-251-2957-6
