Vedoucí práce: Ing. Martin Balík

ii

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

Bakalářská práce Webové služby v .NET 3.5 pomocí Windows Communication Foundation Otakar Kovařík

Vedoucí práce: Ing. Martin Balík

Studijní program: Softwarové Technologie a Management, bakalářský Obor: Softwarové inženýrství Květen 2012

iv

v

Poděkování Rád bych poděkoval Ing. Martinu Balíkovi za jeho rady a trpělivost. Bc. Petře Hejdukové za pomoc s korekcí gramatických a stylistických chyb. Kamarádům za podporu a pomoc při testování aplikace.

vi

vii

Prohlášení Prohlašuji, že jsem 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 Pardubicích dne 25.5.2012

………………………………………….

viii

ix

Abstract The objective of this thesis is a description of web services in the framework of Windows Communication Foundation 3.5. The work includes a tutorial for a creation of web services using C# programming language in Visual Studio 2008 and an implementation of web services and clients in a real life deployment. The first part of the thesis is an introduction dedicated to the framework of Windows Communication Foundation. The following parts include a tutorial and an outline of the use of web services technology using SOAP and RESTful architecture. A further section deals with the actual implementation of the final solution for web services and a WCF web services client. The practical part describes the design, implementation and testing of a file storage that is accessible via HTTP on the internet.

Abstrakt Práce se zabývá popisem webových služeb v rámci frameworku Windows Communication Foundation 3.5, obsahuje tutoriál pro tvorbu webových služeb pomocí programovacího jazyka C# v prostředí Visual Studio 2008, implementaci webových služeb a klienta v reálném nasazení. První část práce je věnována frameworku Windows Communication Foundation. Následující části obsahují tutoriál využití webových služeb pomocí SOAP i RESTful architektury. Následující část řeší samotnou implementaci výsledného řešení webových služeb a klienta WCF webových služeb. Praktická část se zabývá návrhem, realizací a testováním aplikace sloužící jako úložiště souborů, které je dostupné pomocí HTTP na síti internet.

x

xi

Obsah

1

Úvod........................................................................................................................... 1

2

Úvod do WCF a webových služeb ............................................................................ 3 2.1

Počátky Windows Communication Foundation ................................................. 3

2.2

Architektura WCF .............................................................................................. 4

2.3

Architektura webových služeb ........................................................................... 5

2.3.1

RPC ............................................................................................................. 5

2.3.2

RESTful ...................................................................................................... 5

2.3.3

REST-RPC Hybrid ...................................................................................... 5

2.4

Komunikace služeb ............................................................................................ 6

2.4.1

Základní princip SOAP služeb .................................................................... 6

2.4.2

Základní popis komunikace klienta se službou ........................................... 6

2.5

Porovnání SOAP s REST ................................................................................. 7

2.5.1 3

Zprávy SOAP a REST ................................................................................ 8

Tutoriál tvorby webových služeb pomocí WCF ...................................................... 11 3.1

WCF služby obecně .......................................................................................... 11

3.1.1

Volba Bindings ......................................................................................... 11

3.1.2

Basic binding............................................................................................. 11

3.1.3

Web Service (WS) binding ....................................................................... 11

3.1.4

TCP binding .............................................................................................. 11

3.1.5

Web binding .............................................................................................. 12

3.1.6

Endpoints .................................................................................................. 13

3.1.7

Metadata Exchange endpoint .................................................................... 14

3.1.8

Contracts ................................................................................................... 14

3.1.9

ServiceContract ......................................................................................... 14

3.1.10

DataContract ............................................................................................. 15

3.2

RPC SOAP WCF služba .................................................................................. 17

3.2.1 3.3

Konfigurační soubor.................................................................................. 18

RESTful služba................................................................................................. 20

xii 3.3.1

HTTP metody a jejich použití ................................................................... 20

3.3.2

Návrh RESTful služby .............................................................................. 20

3.3.3

URI šablony .............................................................................................. 21

3.3.4

Tvorba interface ........................................................................................ 21

3.3.5

Konfigurační soubor ................................................................................. 22

3.4

Zabezpečení služby .......................................................................................... 23

3.5

Zabezpečení RPC SOAP služby....................................................................... 23

3.5.1

Transport Security ..................................................................................... 23

3.5.2

Message security ....................................................................................... 24

3.5.3

Bindings a nastavení zabezpečení ............................................................. 25

3.5.4

Ověření uživatele služby ........................................................................... 25

3.5.5

Příklad konfigurace služby........................................................................ 26

3.6

Zabezpečení RESTful služby ........................................................................... 27

3.7

Hostování služby pomocí IIS 7.5 ..................................................................... 29

3.8

Klient RPC SOAP webové služby ................................................................... 32

3.8.1 3.9 4

Klient RESTful webové služby ........................................................................ 34

Návrh a realizace řešení souborového úložiště ........................................................ 37 4.1

Specifikace a pokrytí požadavků ...................................................................... 37

4.2

Návrh řešení aplikace ....................................................................................... 38

4.2.1 4.3 5

Tvorba klienta pro WCF webovou službu pomocí Visual Studia 2008 ... 32

Databáze .................................................................................................... 40

Nasazení ........................................................................................................... 40

Testování.................................................................................................................. 43 5.1

Systémové testování ......................................................................................... 43

5.1.1

Nastavení připojení a přihlášení uživatele ................................................ 44

5.1.2

Volba vzdáleného adresáře ....................................................................... 44

5.1.3

Nahrání souboru na úložiště ...................................................................... 45

5.1.4

Stáhnutí souboru z úložiště ....................................................................... 45

5.1.5

Smazání souboru z úložiště ....................................................................... 45

5.2

Uživatelské testování ........................................................................................ 46

5.2.1

Scénář testu ............................................................................................... 46

5.2.2

Test č. 1 ..................................................................................................... 46

5.2.3

Test č. 2 ..................................................................................................... 47

xiii 5.2.4 6

Závěr ........................................................................................................................ 49 6.1

7

Test č. 3 ..................................................................................................... 47

Možnosti dalšího vývoje .................................................................................. 50

Literatura .................................................................................................................. 51

Příloha A – Zdrojový kód tutoriálu ................................................................................. 53 A1 Nastavení interface a jeho implementace v rámci třídy služby ............................. 53 A2 System.serviceModel ze souboru Web.config ...................................................... 54 A3 Implementace klienta služby ................................................................................. 55 Příloha B – Snímky struktury projektů ........................................................................... 57 B1 Struktura řešení implementace služby ................................................................... 57 B2 Struktura řešení implementace klienta ................................................................... 58 Příloha C – Seznam použitých zkratek ........................................................................... 59 Příloha D – UML Diagramy ........................................................................................... 61 UC1 Soubory ............................................................................................................... 61 UC2 Adresáře .............................................................................................................. 62 UC3 Administrace uživatelů ....................................................................................... 63 UC4 Klientská Aplikace .............................................................................................. 63 Příloha E – Uživatelská a instalační příručka ................................................................. 65 Instalace programu ...................................................................................................... 65 Používání programu .................................................................................................... 65 Příloha F – Obsah přiloženého disku .............................................................................. 69

xiv

xv

Seznam ilustrací

Obrázek 1 .NET 3.0 [McMurtry a kol., 2007] .................................................................. 3 Obrázek 2 Architektura WCF [Lowy, 2007] .................................................................... 4 Obrázek 3 SAO [Lowy, 2007] .......................................................................................... 6 Obrázek 4 Komunikace v rámci stejného stroje [Lowy, 2007] ........................................ 7 Obrázek 5 Komunikace v rámci různých strojů [Lowy, 2007] ......................................... 7 Obrázek 6 Volba binding [Lowy, 2007] ......................................................................... 12 Obrázek 7 Koncový bod [Lowy, 2007]........................................................................... 13 Obrázek 8 Nový projekt v programu Visual Studio........................................................ 17 Obrázek 9 Zabezpečení komunikace v rámci transportní vrstvy [Meier a kol., 2008] ... 23 Obrázek 10 Zabezpečení komunikace pomocí šifrování zprávy [Meier a kol., 2008] ... 24 Obrázek 11 Okno programu SelfCert ............................................................................. 29 Obrázek 12 Nastavení privátních klíčů pro certifikát v programu MMC ....................... 30 Obrázek 13 Přidání aplikačního poolu mezi uživatele certifikátu .................................. 31 Obrázek 14 Automatické přidání service reference ve VS2008 ..................................... 33 Obrázek 15 Návrh realizace přístupu k DB .................................................................... 39 Obrázek 16 Datový model databáze ............................................................................... 40 Obrázek 17 Diagram nasazení celkového řešení ............................................................ 41

xvi

xvii

Seznam tabulek

Tabulka 1 Druhy binding, jejich transportní protokol a kódování [Lowy, 2007] ........... 12 Tabulka 2 Příklad URI šablon pro RESTful službu ........................................................ 21 Tabulka 3 Možnosti zabezpečení podle zvoleného binding [Meier a kol., 2008] .......... 25 Tabulka 4 Druhy módů zabezpečení RESTful webové služby [Flanders, 2008] ........... 28 Tabulka 5 Možnosti ověření klienta RESTful webové služby [Flanders, 2008] ............ 28 Tabulka 6 Pokrytí požadavků případy užití .................................................................... 38

xviii

xix

Seznam výpisů kódu

Výpis 1 SOAP požadavek pro webovou službu ............................................................... 8 Výpis 2 SOAP odpověď webové služby ........................................................................... 9 Výpis 3 GET pomocí REST.............................................................................................. 9 Výpis 4 Odpověď na požadavek GET pomocí REST ...................................................... 9 Výpis 5 Základní nastavení binding – konfigurační soubor ........................................... 13 Výpis 6 Základní nastavení binding – programově ........................................................ 13 Výpis 7 Service Contract ................................................................................................ 15 Výpis 8 Service Contract nastavení atributu Namespace ............................................... 15 Výpis 9 Operation Contract ............................................................................................ 15 Výpis 10 Data Contract ................................................................................................... 16 Výpis 11 Data Contract property .................................................................................... 16 Výpis 12 Definování a implementace ServiceContract .................................................. 18 Výpis 13 Nastavení readerQuotas a dalších atributů pro wsHttpBinding....................... 19 Výpis 14 Nastavení atributů WebGet a WebInvoke pro interface RESTful služby ....... 22 Výpis 15 Chování koncového bodu pro RESTful webovou službu ............................... 22 Výpis 16 Nastavení zabezpečení v konfiguračním souboru ........................................... 26 Výpis 17 Nastavení certifikátu pro službu v konfiguračním souboru............................. 27 Výpis 18 Spuštění winhttpcertcfg.exe............................................................................. 31 Výpis 19 WebChannelFactory pro klienta RESTful webové služby .............................. 34 Výpis 20 HttpClient pro klienta RESTful webové služby .............................................. 35

xx

Úvod

1

1 Úvod

V průběhu studia jsem dostal nabídku začít pracovat pro českou firmu vyvíjející aplikace v prostředí .NET. Při seznamování s reálnými projekty jsem brzy musel zjišťovat, co jsou to webové služby a jak je realizovat. Mnoho dnešních aplikací vyžaduje sdílení dat a interakci mezi systémy. V této oblasti jsou webové služby hojně využívány. Webová služba prostřednictvím rozhraní, kterým v rámci sítě zprostředkovává přístup k její funkcionalitě pro uživatele. Ti mohou ke službě přistupovat vzdáleně. Data mezi klientem a službou jsou posílána obalená v komunikačním protokolu webové služby. V internetu je to často HTTP, ale mohou to být jiné protokoly. V tomto zapouzdření data putují po síti ke svému cíli, kde mohou být dále využita. Z různých důvodů jsem se při tvorbě webových služeb setkával pouze s ASMX webovými službami. Tato realizace webových služeb je relativně stará a v současné době není ve frameworku .NET tolik podporována jako dříve. Přitom platforma .NET již delší dobu nabízí nový způsob realizace webových služeb. Realizaci webových služeb pomocí Windows Communication Foundation. Cíle mé bakalářské práce jsou následující. Popsat webové služby v .NET pomocí Windows Communication Foundation. Porovnat SOAP a REST. Vypracovat tutoriál tvorby WCF služeb. Navrhnout a implementovat úložiště souborů, které bude poskytovat komunikační rozhraní s využitím WCF. Implementovat aplikaci, která bude jako klient s webovou službou komunikovat. V kapitole 2 se věnuji úvodu do WCF a webových služeb obecně. Jsou zde popsány počátky a architektura WCF, architektura webových služeb, základní příklady komunikace a porovnání SOAP a RESTful služeb. Kapitola 3 je rozsáhlejší kapitolou tutoriálu tvorby webových služeb pomocí WCF. Obsahuje informace o možnostech nastavení webových služeb pomocí WCF včetně ukázek implementace dílčích částí webové služby. V kapitole jsou zvlášť popsány webové služby založené na vzdáleném volání procedur pomocí SOAP a zvlášť webové služby využívající REST. RESTful webové služby jsou mladší než již dlouhou dobu využívané RPC SOAP služby. REST nabízí jiný přístup ke způsobu implementace i návrhu řešení webové služby. V kapitole 3 jsou také podkapitoly věnované zabezpečení webových služeb, hostování služby pomocí IIS 7.5 na operačním systému

2

Úvod

Windows Server 2008 R2 a podkapitola věnovaná popisu tvorby klienta pro WCF webovou službu. Návrh a realizaci souborového úložiště jsem popsal v kapitole 4. Na základě požadavků pro souborové úložiště zde řeším způsob realizace výsledných aplikací. Pro tvorbu jsem využil poznatky o webových službách, které prezentuji v předchozích kapitolách. Kapitola 5 obsahuje postup testování výsledného řešení aplikací. Věnuji v ní prostor testování pomocí scénářů a zpětné vazbě získané pomocí uživatelského testování.

3

Úvod do WCF a webových služeb

2 Úvod do WCF a webových služeb

2.1 Počátky Windows Communication Foundation Vývoj WCF byl původně veden pod kódovým jménem Indigo. Projekt Indigo vznikl s cílem vyřešit komunikaci mezi službami a práci se službami pro framework .NET [McMurtry a kol., 2007]. Dřívější nejednotný přístup pro tvorbu služeb nabízel různá řešení pro rozdílné scénáře (.NET Remoting, Web Services Enhancements). Jednotlivá řešení se lišila způsobem implementace a použitými technologiemi. Tento stav přinášel možné komplikace a problémy při komunikaci mezi platformami. WCF sjednocuje způsob implementace jednotlivých služeb a nahrazuje předešlé technologie vývoje služeb pro .NET. Windows Communication Foundation je společně s Windows Presentation Foundation (kódové jméno Avalon), Windows CardSpace (kódové jméno InfoCard) a s Windows Workflow Foundation součástí technologie, které se říkalo WinFX. V červnu roku 2006 se tento balík projektů přejmenoval na .NET Framework 3.0. .NET 3.0 se skládá z .NET Frameworku 2.0 a z nových tříd od výše jmenovaných projektů. Většina funkcionality pro WCF se nachází v dynamické knihovně System.Servicemodel.dll a používá namespace System.Servicemodel.

Obrázek 1 .NET 3.0 [McMurtry a kol., 2007]


4

2.2 Architektura WCF V této kapitole jsou popsány základy fungování architektury Windows Communication Foundation. Na obrázku 2 je zobrazena architektura WCF. V klientské části se nachází již zmíněná proxy reprezentující službu [Lowy, 2007]. Po proxy následuje několik kanálů. Každý kanál má určitý úkol. Jedná se například o kódování zprávy (bingy, text, MTOM), bezpečnost a podobně. Poslední kanál je transportní, který přenese zprávu ke službě. Na straně hostitele služby je také řetěz kanálů starající se o přijetí zprávy, dešifrování a další. Poslední kanál předá zprávu k dispečerovi, který poskytne zprávu do zásobníku a zavolá instanci služby.

Obrázek 2 Architektura WCF [Lowy, 2007]

Windows Communication Foundation (WCF) je Software Development Kit (SDK) pro vývoj a nasazení služeb na operační systém (OS) Windows [Lowy, 2007]. WCF sjednocuje programovací postup pro tvorbu služeb pomocí frameworku .NET.

5


2.3 Architektura webových služeb Následující kapitola popisuje druhy architektur použitelných pro realizaci webových služeb pomocí Windows Communication Foundation.

2.3.1 RPC Remote Procedure Call styl návrhu aplikací posílá všechna data od klienta v obálce, a ve stejné obálce jsou data poslaná zpět [Richardson; Ruby, 2007]. Oblíbenou obálkou je simple object access protokol (SOAP), který se využívá pro RPC webové služby v .NET. SOAP je dále posílán pomocí jiných protokolů, jako je například HTTP. Jak již název napovídá, jedná se o vzdálené volání procedur. Podobně, jako bychom přistupovali k metodám v projektu klienta. Ovšem daná procedura není součástí našeho projektu a je vykonávána většinou i v rámci jiného stroje.

2.3.2 RESTful REST, jako takový, není architekturou. REST je desénovým kritériem. RESTful je architekturou orientovanou na zdroje. RESTful služba vypadá jako web. Zdroj je obvykle něco, co může být uloženo v počítači a může se dále reprezentovat jako proud bitů. Jako dokument, řádek databáze, výsledek algoritmu a podobně. Každý zdroj je reprezentován svým jednotným unifikátorem zdroje (URI).

2.3.3 REST-RPC Hybrid Jedná se o služby, které jsou svým principem někde mezi RPC a RESTful architekturou. Často se jedná o uvedení názvu metody v URI zdroje. Poté už nejde o RESTful službu, ale pouze o službu, která se tak může na první pohled tvářit. Například: http://www.flickr.com/services/rest?api_key=xxx&method=flickr.photos.sea rch&tags=penguin Hybridní přístup se sice v praxi může objevovat, ale neodpovídá teorii REST.


6

2.4 Komunikace služeb V této kapitole je popsán princip komunikace SOAP webových služeb. RPC SOAP služby jsou veškeré služby v rámci .NET do verze 3.5 SP1. Obecně je služba funkční jednotka vystavená pro užití z venčí[Lowy, 2007]. Jedná se o evoluční krok navazující na funkce, objekty a komponenty. Service-oriented application (SOA) seskupuje služby do jedné aplikace podobně jako objektově orientovaná aplikace seskupuje objekty.

Obrázek 3 SAO [Lowy, 2007]

2.4.1 Základní princip SOAP služeb Služby jsou vyhledávány díky snadné komunikaci mezi různými systémy. Uvnitř služeb se mohou vyskytovat různé technologie, programovací jazyky apod. Mezi službami se komunikuje pouze předem stanovenými způsoby. WCF služby komunikují pomocí SOAP zprávy, jsou normované. Díky tomu může WCF služba nebo klient komunikovat i se službami nebo klienty, které nejsou vytvořeny pomocí WCF a naopak. Metadata, potřebná pro komunikaci se službou, se publikují pomocí WSDL. Metadata je možné importovat pomocí HTTP-GET nebo jiným standardem pro výměnu metadat. Jednotlivá metadata jsou pak převedena do Common Language Runtime Types (CLR Types) a je možné s nimi dále v aplikaci pracovat. CLR Typy pro .NET jsou třídy, struktury, enumerace a delegáti.

2.4.2 Základní popis komunikace klienta se službou Klient nikdy nekomunikuje se službou přímo. Místo toho využívá proxy pro volání služby. Se službou se dá komunikovat jak v rámci stejného procesu na stejném stroji, tak i v rámci různých procesů i na vzdálených strojích, například pomocí www.


7

Obrázek 4 Komunikace v rámci stejného stroje [Lowy, 2007]

Obrázek 5 Komunikace v rámci různých strojů [Lowy, 2007]

2.5 Porovnání SOAP s REST Tato kapitola pojednává o základních rozdílech mezi SOAP a RESTful webovými službami. SOAP nesoupeří s RESTful webovými službami. Ve skutečnosti je to Remote Procedure Call architektura, která soupeří s Representational State Transfer architekturou. Pravdou je, že každá SOAP webová služba, v současnosti existující, je založená na RPC architektuře. SOAP je s RPC úzce svázán [Richardson; Ruby, 2007]. Zprávy REST se na rozdíl od běžné zprávy, využívající webové služby, neposílají pomocí SOAP. Díky tomu není nutné přistupovat k službám pomocí koncového bodu, ale je možné provádět operace (GET, PUT, POST, DELETE) přímo nad vzdálenými daty reprezentovanými pomocí URL [Blewet, 2011]. Zároveň není nutné data posílat pomocí XML. Díky tomu se mohou reprezentovat i jinak než textově bez nutnosti kódování do Base64 nebo MTOM. REST je podporovaný od .NET Framework 3.5 SP1.

8


2.5.1 Zprávy SOAP a REST Zprávy SOAP jsou obálkou pro data webové služby. Obvykle jsou posílány pomocí další obálky, jako je například HTTP. Oproti tomu REST přistupuje k datům přímo pomocí HTTP [Richardson; Ruby, 2007]. Příklad SOAP Request BasicHttpBinding: POST http://127.0.0.1:50942/Service.svc HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol 2.0.50727.4952) VsDebuggerCausalityData: uIDPo0sZGN9VZ1JNlbNTU2doM+EAAAAAiYnaB7NAB064unymH0ND+Xl4qXc GfZhFgdOw31ajoK0ACQAA Content-Type: text/xml; charset=utf-8 SOAPAction: "http:// moje.cz/IService/DataWrite" Host: 127.0.0.1:50942 Content-Length: 803 Expect: 100-continue Connection: Keep-Alive <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <soap:Body> … Výpis 1 SOAP požadavek pro webovou službu

K HTTP hlavičce je přidaná i struktura zprávy popsaná v metadatech služby. Příklad SOAP Response BasicHttpBinding: HTTP/1.1 200 OK Server: ASP.NET Development Server/9.0.0.0 Date: Thu, 27 Jan 2011 08:36:39 GMT X-AspNet-Version: 2.0.50727 Cache-Control: private Content-Type: text/xml; charset=utf-8 Content-Length: 343 Connection: Close <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">


9

<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <EMDataWriteResult> … Výpis 2 SOAP odpověď webové služby

Příklad REST Request [Cheeso, 2008]: GET /rest/Northwind/Order/11049 HTTP/1.1 Accept: */* Accept-Language: en-us UA-CPU: x86 Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0;) Host: dinoch-2:8080 Proxy-Connection: Keep-Alive Výpis 3 GET pomocí REST

V žádosti je vidět pouze HTTP hlavička. Žádné další informace nejsou pro REST potřebné. Tato žádost si vyžádá získání obsahu z cílového URL. Příklad REST Response [Cheeso, 2008]: HTTP/1.1 200 OK Content-Length: 1189 Content-Type: application/xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 20 Mar 2008 20:34:59 GMT … Výpis 4 Odpověď na požadavek GET pomocí REST

OrderInfoMsg je v tomto případě informace v Plain Old Xml, ale může se jednat i o jiný druh reprezentace dat, například data v JSON apod. Podrobnější rozdíly RESTful návrhu jsou popsány v dalších kapitolách pojednávajících o RESTful službách.

10


11

Tutoriál tvorby webových služeb pomocí WCF

3 Tutoriál tvorby webových služeb pomocí WCF

3.1 WCF služby obecně Kapitola 3 je zaměřena na obecný úvod do tvorby webových služeb pomocí WCF.

3.1.1 Volba Bindings Volba binding je pro službu jedním z klíčových parametrů. Při volbě je nutné položit si otázku, na co a jakým klientům bude služba sloužit. Jak se bude služba využívat a jak chceme službu zabezpečit. Mix možností je velmi komplexní a k ucelenému pohledu je zapotřebí přečíst nejen tento tutoriál, ale čerpat i z jiných zdrojů. Tutoriál je zaměřen na vybraná nastavení, s nimiž jsem se setkal při přípravě a realizaci této práce. Následuje stručný popis vybraných bindings.

3.1.2 Basic binding Používá třídu BasicHttpBinding, která umožňuje použít službu s klientem používajícím ASMX služby [Lowy, 2007]. Nové služby mohou pracovat se starými klienty. Kompatibilita s některými klienty mimo platformu .NET bohužel není silnou stránkou WCF 3.5. V mnoha případech je rozumnější využít starých asmx služeb. S novými verzemi .NET se tento stav zlepšuje. Například sloučení výsledného WSDL do jednoho souboru od WCF 4.0.

3.1.3 Web Service (WS) binding Využívá třídu WSHttpBinding, která užívá pro transport HTTP nebo HTTPS. Umožňuje využívat mnoho dalších nastavení pro transakce, bezpečnost apod.

3.1.4 TCP binding Užívá třídu NetTcpBinding, která pomocí TCP komunikuje mezi jednotlivými stroji za použití internetu. Umožňuje využívat mnoho dalších nastavení pro transakce,


12

bezpečnost apod. Optimalizuje komunikaci WCF s WCF. Je nutné, aby služba i klient podporovali WCF.

3.1.5 Web binding WebHttpBinding slouží pro implementaci RESTful služeb od WCF 3.5 [Flanders, 2008]. Společně s dalšími prvky knihovny System.Service.Model.Web.dll umožňuje snazší tvorbu RESTful služeb. Name

Transport

Encoding

BasicHttpBinding

SYSTÉM/HTTPS

Text, MTOM

NetTcpBinding

TCP

Binary

NetPeerTcpBinding

P2P

Binary

NetNamedPipeBinding

IPC

Binary

WSHttpBinding

HTTP/HTTPS

Text, MTOM

WSFederationHttpBinding

HTTP/HTTPS

Text, MTOM

WSDualHttpBinding

HTTP

Text, MTOM

NetMsmqBinding

MSMQ

Binary

MsmqIntegrationBinding

MSMQ

Binary

Tabulka 1 Druhy binding, jejich transportní protokol a kódování [Lowy, 2007]

Diagram na obrázku 6 znázorňuje možný postup pro volbu binding pro RPC SOAP WCF webovou službu.

Obrázek 6 Volba binding [Lowy, 2007]

13


Je-li cílem vytvořit RESTful webovou službu, je volba snadná. Použije se vždy WebHttpBinding.

3.1.6 Endpoints Koncový bod je důležitou součástí nastavení každé služby [Lowy, 2007]. Skládá se ze tří částí, které se zkráceně označují jako ABC. Jedná se o Address, Binding a Contract. Koncový bod slouží jako interface služby. Pomocí ABC je služba definována. Pak je možné k ní přistupovat.

Obrázek 7 Koncový bod [Lowy, 2007]

Jeho nastavení se provádí v souboru web.config, případně programově. <system.serviceModel> <services> <service name = „MyNamespace.MyService“> <endpoint address = „http://localhost:8000/MyService/“ binding = „wsHttpBinding“ contract = „MyNamespace.ImyContract“ /> Výpis 5 Základní nastavení binding – konfigurační soubor

V rámci jedné služby je možné mít i více koncových bodů. ServiceHost host = new ServiceHost(typeof(MyService)); Binding wsBinding = new WSHttpBinding( ); Binding tcpBinding = new NetTcpBinding( ); host.AddServiceEndpoint(typeof(IMyContract),wsBinding, "http://localhost:8000/MyService"); host.AddServiceEndpoint(typeof(IMyContract),tcpBinding, "net.tcp://localhost:8001/MyService"); host.Open( ); Výpis 6 Základní nastavení binding – programově


14

Nastavení koncových bodů je komplexnější. Více jsou koncovým bodům věnovány kapitoly zaměřené na RPC SOAP služby a RESTful služby. V závislosti na požadovaných vlastnostech služby jsou nastavovány další parametry koncového bodu.

3.1.7 Metadata Exchange endpoint MEX koncový bod slouží pro poskytování metadat služby pomocí HTTP-GET pro klienta služby [Lowy, 2007]. Dodržuje se standard, který je ve WCF reprezentován pomocí IMetadataExchange interface. Z MEX koncového bodu se při implementaci klienta pomocí .NET a Visual Studia generuje automaticky proxy třída v rámci Service Reference.

3.1.8 Contracts Služba se skládá z kontraktů, které určují, jak je možné definované služby využívat. Kromě níže popsaných kontraktů existuje i FaultContrakt, v této práci popisován nebude. 

Service contract. Popisuje, jaké operace je možné v rámci služby provádět a volat [Lowy, 2007].



Data contract. Definuje, které datové typy jsou službou přijímané a odesílané. Kromě implicitně definovaných typů jako je int, string atd. je možné explicitně nadefinovat kontrakt podle vlastních potřeb.



Message contract. Pomocí tohoto kontraktu je možné přímo ovlivnit posílanou zprávu. Message contract se hodí využívat pouze v případě, pokud již existuje formát zprávy, pomocí kterého je nutné komunikovat. V jiném případě není doporučováno používat MessageContract.

Následuje podrobnější popis vybraných kontraktů.

3.1.9 ServiceContract Pomocí service kontraktu je označováno rozhraní sloužící pro definování jednotlivých metod, které bude služba nabízet navenek. Každá metoda, která má být službou použita, musí být označena pomocí OperationContract. Třída implementující dané rozhraní poté slouží pro práci se službou. Následuje příklad kódu definující rozhraní IMyContract s jednou metodou MyMethod(). Třída MyService implementuje rozhraní. Metoda MyMethod vrací datový typ string s obsahem „Hello“.

15


[ServiceContract] interface IMyContract { [OperationContract] string MyMethod( ); } class MyService : IMyContract { public string MyMethod( ) { } } Výpis 7 Service Contract

Při použití ServiceContract je možné určit název jmenného prostoru, případně další atributy. [ServiceContract(Namespace = "MyNamespace")] interface IMyContract {...} Výpis 8 Service Contract nastavení atributu Namespace

U OperationContract je možné určit jméno operace. [ServiceContract] interface IMyContract { [OperationContract(Name = "SomeOperation")] void MyMethod(string text); } Výpis 9 Operation Contract

3.1.10 DataContract Datový kontrakt je používán, pokud je nutné nadefinovat vlastní strukturu kontraktu. Pokud nechceme pracovat pouze se základními typy a potřebujeme pomocí služby přenášet komplexnější informace, datový kontrakt je řešením. Strukturu kontraktu je možné definovat přímo na jednotlivá pole pomocí označení DataMember.


16

[DataContract] struct Contact { [DataMember] public string FirstName;

}

[DataMember] public string LastName; Výpis 10 Data Contract

DataMember je možné použít i na jednotlivé property. [DataContract] struct Contact { string m_Name; [DataMember] public string FirstName { get {...} set {...} } } Výpis 11 Data Contract property

WCF se stará o automatickou serializaci a deserializaci tříd a struktur, které jsou označeny jako DataContract nebo MessageContract. Výjimkou je například použití REST Starter Kitu pro tvorbu klienta pro RESTful službu.


17

3.2 RPC SOAP WCF služba Tato kapitola obsahuje vzorový příklad implementace služby pro přenos dat pomocí BasicHttpBinding. RPC služba slouží k zpřístupnění procedur pro klienta. Prvně je nutné založit nový projekt ve Visual Studiu „File/NewProject”. Zvolí se šablona pro WCF Service Application.

Obrázek 8 Nový projekt v programu Visual Studio

Automaticky se vytvoří struktura projektu obsahující Web.config, třídu Service1.svc.cs a interface IService1.cs. Služba bude využívat wsHttpBinding a obsahuje vzorový ServiceContract a DataContract, který se využívá v metodách třídy Service1.svc.cs. Třída a její interface se upraví podle poznatků z předchozích kapitol. Třída Service bude obsahovat metodu GetFile(), která bude vracet požadovaný stream. Její implementaci je možné najít v příloze A1. Je nutné importovat knihovnu System.IO.

18


[ServiceContract] public interface IService1 { [OperationContract] Stream GetFile(); } public class Service1 : IService1 { public Stream GetFile() {…} } Výpis 12 Definování a implementace ServiceContract

3.2.1 Konfigurační soubor Konfigurační soubor Web.config pro BasicHttpBindig s povolením proudového přenosu je k dispozici v příloze A2. V dalším textu bude následovat popis jednotlivých elementů konfigurace. Zde budou popsány použité nastavaní konfigurace. Služba má atributem specifikovaný název a behaviorConfiguration. Atribut konfigurace chování odkazuje na jméno chování nastaveném v tagu serviceBehaviors. U chování služby je nastaven serviceMetadata httpGetEnabled na hodnotu „pravda“. Díky tomu se metadata služby budou publikovat na adrese služby plus „?wsdl“. V případě, že je nastaveno „nepravda“ nebo služba není založená na HTTP nebo HTTPS, „?wsdl“ je ignorováno. Nastavení serviceDebug includeExceptionDetailInFaults je na hodnotu „nepravda“. Díky tomu se klientovi nezobrazí informace o průběhu výjimek. Tato možnost se může nastavit na hodnotu „pravda“ z důvodů ladění služby. Nastavení „pravda“ není doporučeno z bezpečnostních důvodů. Podrobný výpis o výjimkách obsahují informace o implementaci služby a mohou být zneužity. Koncový bod obsahuje v atributech informace o svém jméně, volbě binding pro daný koncový bod, jméno kontraktu, ke kterému se váže, a jméno konfigurace pro binding. BindingConfiguration se nachází v binding, které je vnořeno v tagu reprezentující název zvoleného binding, pro něhož se konfigurace provádí. V příkladu tutoriálu se jedná o basicHttpBinding. Samotná konfigurace obsahuje jméno konfigurace, maximální délku zprávy, druh přenosu a druh kódování. Druhý koncový bod je nazýván Metadata Exchange, zkráceně MEX. Jedná se o speciální koncový bod, kterým se vystaví metadata použitá k popsání služby [Barnes, 2006]. Díky tomu je pak možné generovat proxy třídy pro klienty služby. Pro generování těchto tříd je možné použít svcutil.exe nebo přímo Visual Studio. Atribut contract zůstává vždy stejný a určuje interface, který MEX obsahuje. Atribut binding se vyplní podle použitého binding. V případě přenosu většího množství dat ve zprávě, je nutné také navýšit readerQuotas pro zvolený binding.

19


<wsHttpBinding> Výpis 13 Nastavení readerQuotas a dalších atributů pro wsHttpBinding


20

3.3 RESTful služba V kapitole 3.3 je možné získat informace o RESTful webových službách a přístupu k jejich realizaci pomocí WCF 3.5. Navržení a implementace RESTful služby je výrazně odlišné od RPC služby. RPC služba prakticky představuje zpřístupnění procedur klientovi na dálku. U RESTful služeb se jedná o jiný způsob návrhu i použití služby. Rozdíly budou popsány v následující kapitole. Na rozdíl od SOAP služeb, RESTful služba nemá jednu URL sloužící k přístupu ke všem procedurám služby. Místo toho nabízí jedinečné URI pro každý zdroj, s kterým se dá pracovat pomocí HTTP metod [Skonnard, 2008]. Díky využití HTTP metod nabízí RESTful služba jednotný interface [Flanders, 2008]

3.3.1 HTTP metody a jejich použití 

GET

slouží pro získání zdroje,



POST

vytváří nový zdroj,



PUT

aktualizuje existující zdroj,



DELETE

odstraňuje zdroj.

3.3.2 Návrh RESTful služby Důležitým krokem pro správné navrhnutí RESTful služby je správné identifikování zdrojů, které bude služba nabízet [Skonnard, 2008]. Zároveň je důležité přejít od sloves, většinou určující akci, kterou metoda provede k podstatným jménům, která se budou v rámci URI prezentovat jako jednotlivé zdroje. Každý zdroj bude definován URI. Pomocí tohoto identifikátoru k němu bude přistupováno.


21

3.3.3 URI šablony Jedinečná URI je vytvářena pomocí URI šablon. Špatně navržená šablona by byla taková, která by obsahovala akci, jenž se má pod danou URI provést. Následující tabulka názorně ukazuje možnosti návrhu URI šablon. URI šablona

Metoda

RPC ekvivalent

PUT

users/{username}

addUser

GET

users/{username}

getUser

PUT

users/{username}

editUser

DELETE

users/{username}

deleteUser

GET

users/{username}/friends

getUsersFriends

GET

users/{username}/friends/id

getUsersFriend

PUT


editUsersFriend

DELETE


deleteUsersFriend

Tabulka 2 Příklad URI šablon pro RESTful službu

Pro filtraci šablony je možné použít ?tag={tag}, jenž je vkládán na konec šablony.

3.3.4 Tvorba interface Interface je definován pomocí ServiceContract jako RPC SOAP služba, ale jednotlivé metody mají navíc k atributu OperationContract jestě atribut WebGet nebo WebInvoke. WebGet se používá v případě, kdy se jedná o HTTP metodu GET. WebInvoke, je použit ve všech následujících případech. Při nastavování atributu WebInvoke je důležité specifikovat jméno metody, která bude k danému kontraktu přiřazena. V následujícím příkladě je interface, který má dvě metody. Metoda ListFiles prolistuje všechny soubory na základě ID adresáře, který je v rámci URI šablony reprezentován hodnotou dirId v hranatých závorkách. Název této hodnoty v šabloně musí odpovídat názvu parametru v metodě ListFiles. Metoda PutSomething odpovídá HTTP metodě POST, a proto je v atributu WebInvoke explicitně určená metoda POST. Metoda PutSomething má také více vstupních parametrů. Z tohoto důvodu je nutné nastavit BodyStyle u atribudu WebInvoke na hodnotu Wrapped.


22

[ServiceContract(Namespace = "")] public interface IStorage { [WebGet(UriTemplate = "files/{dirId}", BodyStyle = WebMessageBodyStyle.Bare)] [OperationContract] FileInformations ListFiles(int dirId); [WebInvoke(UriTemplate = "things", Method = "POST", BodyStyle = WebMessageBodyStyle.Wrapped)] [OperationContract] bool PutSomething(string name, string info, int friendId); } Výpis 14 Nastavení atributů WebGet a WebInvoke pro interface RESTful služby

Takto nastavené rozhraní bude dále implementováno stejným způsobem jako rozhraní pro SOAP webovou službu.

3.3.5 Konfigurační soubor Tvorba konfiguračního souboru je podobná jako u SOAP webové služby. Důležité je zvolit pro koncový bod webHttpBinding a přidat mu behaviorConfiguration. Vzor nastavení behavior pro koncový bod je v následujícím výpisu kódu. <endpointBehaviors> <webHttp /> Výpis 15 Chování koncového bodu pro RESTful webovou službu


23

3.4 Zabezpečení služby Chceme-li, aby webovou službu mohl používat pouze oprávněný uživatel, je nutné službu zabezpečit proti zneužití. Pokud služba není veřejná, je nutné, aby se dala zjistit a ověřit identita uživatele. Přenášíme-li pomocí webové služby informace, které jsou citlivé, je důležité zamezit možnému přečtení zprávy v případě odposlouchávání komunikace.

3.5 Zabezpečení RPC SOAP služby 3.5.1 Transport Security Zabezpečení na úrovni transportní vrstvy nabízí ošetření přenosu mezi dvěma komunikačními body (služba a klient) [Meier a kol., 2008]. Pokud se mezi klientem a službou nachází další transportní systém, je nutné, aby mezi dalšími body komunikace bylo navázáno také šifrované spojení. Šifrování je zprostředkováno v rámci transportní vrstvy. Každý transportní protokol (TCP, HTTP a další) má svůj vlastní mechanismus předávání identifikačních údajů a pro ochranu přenášené zprávy. Nejčastěji je používán přístup pomocí Secure Sockets Layer (SSL).

Obrázek 9 Zabezpečení komunikace v rámci transportní vrstvy [Meier a kol., 2008]

Transport security je využíván v následujících scénářích: 

Zpráva je posílána přímo ze služby ke klientovi a zpráva nebude přeposílána mezi dalšími systémy.



Služba i klient jsou součástí intranetu.


24

Výhody transport security: 

Nabízí dobrou součinnost mezi různými systémy.



Dosahuje lepšího výkonu oproti zabezpečení zpráv.

3.5.2 Message security Zabezpečení zprávy samotné nabízí oproti zabezpečení na úrovni transportní vrstvy jiný přístup. Všechny informace jsou zapouzdřené v každé zprávě použitím specifikace WS Security [Meier a kol., 2008]. Tato volba dává větší flexibilitu. Je možné použít jakékoli nastavení zabezpečení, které je nezávislé na transportní vrstvě. Zpráva se zašifruje přímo v rámci služby nebo klienta a celou svoji cestu ke komunikačnímu partnerovi absolvuje zašifrovaná.

Obrázek 10 Zabezpečení komunikace pomocí šifrování zprávy [Meier a kol., 2008]

Message security je využívána v následujících scénářích: 

Zpráva je posílána mezi více službami nebo může být jinak přesměrovávána.



Klient služby přistupuje ke službě pomocí internetu.

Výhody message security: 

Zabezpečuje zprávu od klienta až ke službě bez ohledu na cestu zprávy.



Zabezpečení zprávy je nezávislé na transportní vrstvě.

Nevýhody message security: 

Může omezit výkon ve srovnání se zabezpečením na transportní vrstvě, protože každá zpráva musí být zvlášť šifrována.



Neumožňuje použití se staršími ASMX službami, jelikož vyžaduje, aby klient i služba podporovali WS Security specifikace.


25

3.5.3 Bindings a nastavení zabezpečení Následující tabulka 3 uvádí možnosti zabezpečení a přednastavené volby pro jednotlivé bindings. Jméno

Žádné

Transport

Message

✓ (přednastaveno)

✓

✓

wsHttpBinding

✓

✓


netTCPBinding

✓


✓

netPeerTCPBinding

✓


✓

netNamedPipeBindi ng

✓


X

wsFederationHttpB inding

✓

X


wsDualHttpBinding

✓

X


basicHttpBinding

✓ ✓ (přednastaveno) Tabulka 3 Možnosti zabezpečení podle zvoleného binding [Meier a kol., 2008]

netMsmqBinding

✓

Jednotlivé způsoby zabezpečení je možné kombinovat dohromady nebo provozovat v mixovaném módu. Transport a message zabezpečení umožňuje netMsmqBinding. Mixovaný mód umožňují basicHttpBinding, netTCPbinding, netPeerTCPBinding a wsHttpBinding.

3.5.4 Ověření uživatele služby V závislosti na nastavení zabezpečení přenosu informací je možné nastavit několik způsobů identifikace a ověření klienta služby. Možnosti ověření pro transport security: 

None. Neproběhne žádné ověření.



Basic. Tato volba je možná jen pro HTTP. Uživatel je ověřován pomocí svého uživatelského jména a hesla vůči active directory. Citlivé údaje, jako je například heslo, jsou transportovány pouze pomocí Base64 kódování. Tato volba není velmi bezpečná. Pro zajištění komunikace se používá SSL certifikát.


26



NTLM. Tato volba je možná jen pro HTTP. Ověření probíhá na základě chellange-response schématu vůči Windows účtu. Je používán process identity nebo SSL certifikát při použití HTTP.



Windows. Umožní WCF použít Kerberos v rámci domény nebo NTLM v případě nasazení v uživatelské skupině. Tato volba používá Windows token. Ověření probíhá vůči active directory. Je používán process identity nebo SSL certifikát při použití HTTP.



Certificate. Klient použije X.509 certifikát, který je službou využit pro získání důvěry. Služba je ověřená pomocí certifikátu služby nebo SSL certifikátu v případě HTTP.

Možnosti ověření pro message security: 

None. Neproběhne žádné ověření.



Windows. Umožní WCF použít Kerberos v rámci domény nebo NTLM v případě nasazení v uživatelské skupině. Tato volba používá Windows token. Ověření probíhá vůči active directory. Je používán process identity.



Username. Klient služby poskytne uživatelské jméno a heslo. Služba poté provede ověření naproti Windows, použitím membership provider nebo použitím vlastní validace podle volitelných parametrů. Pro šifrování komunikace je používán certifikát služby.



Certificate. Klient použije X.509 certifikát, který je službou využit pro získání důvěry. Služba je ověřená pomocí certifikátu služby.



Issue token. Klient a služba závisí na STS isue tokenu, kterému klient a služba důvěřují.

3.5.5 Příklad konfigurace služby Uvedený výpis kódu obsahuje nastavení konfiguračního souboru pro SOAP službu, který využívá wsHttpBinding s message security a ověření pomocí uživatelského jména a hesla. <wsHttpBinding> <security mode="Message"> <message clientCredentialType="UserName"/> Výpis 16 Nastavení zabezpečení v konfiguračním souboru

27


Pro dokončení nastavení je také nutné nastavit certifikát pro službu v elementu behaviours. Nastavení je provedeno podle příkladu uvedeném ve výpisu 17. <serviceBehaviors> <serviceCredentials> <serviceCertificate findValue="CertificateName" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName" /> <userNameAuthentication userNamePasswordValidationMode="Custom" customUserNamePasswordValidatorType= "Namespace.UserValidator, Namespace" /> Výpis 17 Nastavení certifikátu pro službu v konfiguračním souboru

V elementu serviceCertificate je definováno jméno zvoleného certifikátu, jeho umístění v počítači a způsob nalezení certifikátu. V předchozím výpisu je navíc zvolen vlastní způsob ověření uživatele a jeho hesla, který je implementován ve třídě UserValidator. Má-li mít služba vlastní způsob validace, je nutné, aby třída pro validaci implementovala rozhraní UserNamePasswordValidator a metoda Validate byla přepsána vlastní validací.

3.6 Zabezpečení RESTful služby Nastavení zabezpečení a nabízené možnosti v rámci WCF pro RESTful služby pomocí webHttppBinding nejsou tak rozsáhlé jako u RPC SOAP webových služeb. Zabezpečení koncového bodu je nastavováno pomocí vlastnosti WebHttpSecurity v rámci WbHttpBinding [Flanders, 2008]. Nastavení módu zabezpečení, jenž je službou vyžadován, se provede pomocí WebHttpSecurityMode. Způsob ověření klienta je nastavován pomocí vlastnosti HttpTransportSecurity. V následující tabulce 4 jsou uvedeny možnosti nastavení módu zabezpečení.


28

Hodnota

Popis

None

Výchozí nastavení. Koncový bod nebude vyžadovat žádný druh zabezpečení.

Transport

Koncový bod bude vyžadovat SSL.

Koncový bod bude vyžadovat ověření klienta, ale nebude vyžadovat SSL. Tabulka 4 Druhy módů zabezpečení RESTful webové služby [Flanders, 2008]

TransportCredentialOnly

HttpTransportSecurity a ověření klienta se většinou nastaví na ClientCredentialType, který určuje, jaký způsob ověření klienta se použije. Další možností je ProxyCredentialType související s nastavením proxy na straně klienta a je použitelný pouze na straně WCF klienta. Třetí a poslední možností je Realm, která není explicitně určena. Následující tabulka 5 zobrazuje možnosti nastavení ověření klienta.

Hodnota

Popis

Výchozí nastavení. Žádné ověření není vyžadováno. Klient se musí prokázat použitím HTTP Basic Basic authentifikačního protokolu (RFC 2617). Klient se musí prokázat použitím HTTP Digest authentifikačního protokolu (RFC Digest 2617). Klient se musí prokázat použitím NTLM Ntlm protokolu. Klient se musí prokázat pomocí Kerberos. V případě nemožnosti použití Kerberos se Windows využije NTLM. Klient se musí prokázat platným certifikátem Certificate k serveru. Tabulka 5 Možnosti ověření klienta RESTful webové služby [Flanders, 2008] None

Nevýhodu představuje situace, kdy má být klient ověřen pomocí uživatelského jména a hesla, je nutné použít Active Directory nebo zprávu zpracovat pomocí RequestInterceptor. Tento proces je oproti RPC SOAP způsobu implementace volitelného uživatelského validátoru mnohem komplikovanější [Kalman, 2011a, 2011b]. Díky této nepodpoře je ověření a zabezpečení RESTful webové služby ve WCF 3.5 mnohem méně přístupné a podporované, pokud ověření nemá být pomocí menší množiny podporovaných způsobů ověření nebo výrazně náročnější implementace. Implementace RequestInterceptor pro volitelnou validaci pomocí uživatelského jména a hesla je nad rámec této práce.

29


3.7 Hostování služby pomocí IIS 7.5 Cílem této kapitoly je seznámení s kroky, které je nutné provést pro úspěšné nasazení služby tak, aby byla přístupná z internetu. Jedná se o instalaci Internet Information Servicces na OS Windows Server 2008 R2, základní nastavení aplikačního poolu pro hostování služby, tvorba certifikátu a zpřístupnění certifikátu. Pro úspěšné nasazení služby pomocí Internet Information Services na Windows Server 2008 R2 je nejdříve nutné nainstalovat IIS na server. Instalace může proběhnout pomocí programu Server Manager. V programu Server Manager se přidá nová role pro IIS. Při přidání nové role je nutné zvolit i podporu pro ASP.NET. Pokud by byla nainstalována role pro IIS bez ASP.NET, nebylo by možné na IIS webovou WCF službu hostovat. V případě použití šifrování přenosu dat mezi službou a klientem je nutné použít certifikát. Pakliže není certifikát vydaný certifikační autoritou a scénář využití webové služby to umožňuje, alternativou je vygenerování certifikátu s vlastním podpisem. Tento certifikát lze vygenerovat například pomocí programu SelfCert. Program SelfCert byl vytvořen firmou Pluralsight a je volně ke stažení.

Obrázek 11 Okno programu SelfCert

Je-li certifikát k dispozici, musí se certifikátu nastavit možnost přístupu pro aplikační pool, ve kterém běží webová služba. Toto je nutné u certifikátu, který byl vytvořen nebo získán od certifikační autority. Certifikát musí být nastaven tak, aby důvěřoval uživateli, který odpovídá použitému aplikačnímu poolu. Toto nastavení je možné udělat v programu Microsoft Management Console.


30

Postup v programu MMC je následující: 

V menu zvolit File > Add/Remove Snap-in.



V nabídce Available snap-in zvolit Certificates.



Z Certificates snap-in zvolit Computer account.



V Select Computer zvolit Local computer.



Potvdit pomocí OK.



Zvolit umístění certifikátu a stisknout pravé tlačítko myši.



Podle obrázku 12 zvolit volbu All Tasks > Manage Private Keys…



Zvolit možnost Add… u Group or user names.



Vložit nové jméno do kolonky Enter the object names to select podle šablony IIS AppPool\DefaultAppPool. Na místo DefaultAppPool doplnit jméno aplikačního poolu, který odpovídá zvolené webové službě. Vzor je na obrázku 13.



Nově přidanému aplikačnímu poolu nastavit Full kontrol pro práci s certifikátem v kolonce Permissions for SYSTEM.

Obrázek 12 Nastavení privátních klíčů pro certifikát v programu MMC

Na závěr je nutné umožnit procesu přístup k soukromým klíčům certifikátu. Tuto akci lze realizovat pomocí programu winhttpcertcfg. Program se spouští z příkazové řádky. V následujícím výpisu 18 je vidět nastavení vstupních parametrů.

31


Obrázek 13 Přidání aplikačního poolu mezi uživatele certifikátu C:\Windows\system32>winhttpcertcfg -g -c LOCAL_MACHINE\My -s myCertificate -a IIS AppPool\myAppPoolName Výpis 18 Spuštění winhttpcertcfg.exe

Pro úspěšné zveřejnění WSDL webové služby je potřeba nastavit pro webovou stránku, která slouží jako umístění aplikace s webovou službou v systému IIS, Host Name. Nastavení Host Name je možné v menu Actions pod volbou Bindings. Hodnota Host Name musí být stejná s umístěním webové služby. Po této volbě bude k dispozici zpřístupnění WSDL služby ve webovém prohlížeči. Další důležitou volbou webové stránky IIS sloužící pro WCF webovou službu je nastavení limitů v nabídce Actions Limits. Zde lze nastavit maximální limit pro přenos v bytech a čas připojení.

32


3.8 Klient RPC SOAP webové služby Pro implementaci klienta je nutné importovat sevice kontrakt. Používá-li klient WCF, vygeneruje se z existující služby proxy, která zapouzdří službu. V případě používání Visual Studia je nejsnazší přidat do projektu Service Reference. Jako alternativu je možné použít SvcUtil.exe, které proxy generuje. Klient zároveň potřebuje vědět, kde se služba nachází a jak k ní přistupovat. Tyto informace jsou dostupné v konfiguračním souboru klientské aplikace. Konfigurace pokrývá informace o koncových bodech služby a má stejné schéma jako u hostitele služby. Je nutné mít i stejný binding, jako má služba, ke které se bude klient připojovat.

3.8.1 Tvorba klienta pro WCF webovou službu pomocí Visual Studia 2008 Konfigurace klient je pomocí VS2008 jednoduchá. Stačí v Solution Exploreru po stisku pravého tlačítka vybrat možnost AddServiceReference a zvolit umístění běžící služby, ke které se bude vytvářet klient. Přidáním ServiceReference je automaticky vygenerována proxy třída a soubor App.config projektu se aktualizuje s nastavením pro připojení ke koncovému bodu webové služby. Použije se k tomu MEX koncový bod pro získání informací a metadat o službě. Pokud se pro generování metadat použijí informace získané přímo od služby samotné, v žádném případě není možné zasahovat do konfiguračního souboru App.config pro klienta služby. Tento konfigurační soubor je předvyplněn přesně podle specifikace služby, kterou o sobě sama služba navenek zveřejní. Pro volání služby je nezbytné vytvořit novou instanci vygenerované proxy třídy pro službu. Z ní se pak mohou volat metody služby. Volba přidání Service Reference je znázorněna na obrázku 14.


33

Obrázek 14 Automatické přidání service reference ve VS2008

Implementace volání služby je na straně klienta snadná. Její příklad je ve výpisu 17. ServiceReference1.Service1Client service = new ServiceReference1.Service1Client(); Stream input; input = service.GetFile(); Výpis 17 Implementace služby na straně klienta

Kompletní implementace vzorového klienta je k nahlédnutí v příloze A3. Použití RPC SOAP webové služby v klientovi pomocí WCF 3.5 je velmi snadné a Visual Studio umožňuje snadné generování proxy tříd potřebných k přístupu ke službě.


34

3.9 Klient RESTful webové služby RESTful webové služby bohužel neumožňují automatické generování proxy tříd, jako to nabízí realizace webových služeb pomocí klasického RPC SOAP přístupu. WCF 3.5 nabízí možnost, jak přistupovat k RESTful webové službě bez přímého použití HTTP programování [Skonnard, 2008]. Pro použití této techniky je nutné mít na straně klienta stejně definovaný interface jako je na straně webové služby. Na základě tohoto interface se vygeneruje WCF kanál využívající třídu WebChannelFactory, která je součástí WCF 3.5. Tato třída umožňuje vytvoření mapování volání metod pomocí atributů WebGet a WebInvoke. Výpis kódu 19 názorně ukazuje, jak tento proces realizovat. Zároveň je na tomto příkladu vidět, jak je možné přímo přistupovat k metodě webové služby. WebChannelFactory cf = new WebChannelFactory(new Uri("http://localhost:49733/Storage.svc/")); IMyRESTClient channel = cf.CreateChannel(); List<string> dirs = new List<string>(); try { dirs = channel.ListDirs(); } catch {…} Výpis 19 WebChannelFactory pro klienta RESTful webové služby

Další možností, jak přistupovat k RESTful webové službě v rámci frameworku WCF 3.5, je použití WCF REST Starter Kitu. Tento kit již není ze strany firmy Microsoft podporován a v novějších verzích frameworku jsou nové způsoby konzumace RESTful webových služeb. WCF REST Starter Kit obsahuje několik knihoven. Tato sada umožňuje jiný přístup implementace RESTful webových služeb nebo klientů. Implementace pomocí možností WCF REST Starter Kitu je znázorněna ve výpisu 20. Získaná data pomocí třídy HttpClient je nutné ještě deserializovat. Deserializace je v následujícím příkladu pomocí třídy DataContractSerializer.


35

HttpClient http = new HttpClient("http://localhost:49733/Storage.svc/"); dir = "files/" + dirId.ToString(); Uri uri = new Uri(dir, UriKind.Relative); HttpResponseMessage resp = null; HttpContent content = null; try { resp = http.Get(uri); content = resp.Content; } catch {…} DataContractSerializer ser = new DataContractSerializer(typeof(FileInformations)); FileInformations fis= (FileInformations)ser.ReadObject(content.ReadAsStream()); Výpis 20 HttpClient pro klienta RESTful webové služby

36


Návrh a realizace řešení souborového úložiště

37

4 Návrh a realizace řešení souborového úložiště

V této kapitole rozeberu postupný proces návrhu a realizace aplikace.

4.1 Specifikace a pokrytí požadavků Souborové úložiště má nabízet uživateli pohodlnou možnost uložení, stahování a sdílení souborů s dalšími uživateli. Požadavky na službu jsou popsány v následující části. Funkční požadavky 

FP1 listování adresářem v úložišti



FP2 stáhnutí souboru z úložiště



FP3 uložení souboru do úložiště oprávněným uživatelem



FP4 vytvoření adresáře v úložišti oprávněným uživatelem



FP5 smazání prázdného adresáře oprávněným uživatelem



FP6 založení nového uživatele oprávněným uživatelem



FP7 editace role uživatele oprávněným uživatelem



FP8 smazání uživatele oprávněným uživatelem



FP9 klientská aplikace umožňuje volbu pracovního adresáře úložiště



FP10 klientská aplikace umožňuje volbu pracovního adresáře na lokálním stroji



FP11 ověření role uživatele před provedením akce omezené oprávněním



FP12 získání seznamu všech adresářů úložiště



FP13 smazání souboru z úložiště



FP14 smazání souboru z lokálního adresáře



FP15 změna svého uživatelského hesla

Nefunkční požadavky 

NP1 služba bude přístupná na internetu



NP2 služba poběží na OS Windows Server 2008 R2


38



NP3 služba bude hostována s pomocí IIS 7.5



NP4 klientská aplikace poběží na OS Windows 7

Nefunkční požadavky NP1 až NP3 jsou pokryty díky nasazení webových služeb v rámci Virtuálního Serveru firmy ASPone, který poskytuje prostředí OS Windows Server 2008 R2 s IIS7.5 s vlastní IP adresou přístupnou z internetu. NP4 je pokryt díky použití platformy .NET pro vývoj výsledné aplikace. Diagramy případů užití pokrývající jednotlivé požadavky, jsou uvedeny v příloze D. Požadavek

UC1

UC2

UC3

UC4

✓

FP1 FP2

✓

FP3

✓

FP4

✓

FP5

✓

FP6

✓

FP7

✓

FP8

✓

FP9

✓

FP10

✓

FP11

✓

✓

✓

FP12 FP13

✓

✓ ✓

FP14 ✓

FP15

Tabulka 6 Pokrytí požadavků případy užití

4.2 Návrh řešení aplikace Službu i klienta implementuji v prostředí Visual Studia 2008 pomocí frameworku .NET 3.5. Uživatelské prostředí klienta je realizováno pomocí WinForms aplikace. Projekt služby i klienta jsem rozvrhl do celkového řešení, které se skládá z několika projektů. V případě klienta se jedná o projekt uživatelského rozhraní (ClientApplication), projekt pro samostatnou realizaci rozhraní a tříd klientů (StorageClient), pomocný

39


projekt obsahující oddělené třídy (Library) a projekt, který se stará o spuštění UI (CoreApp). Struktura implementace řešení klienta je dostupná v příloze B2. V případě služeb se jedná o projekt SOAP služby (WcfService), projekt REST služby (WcfServiceREST) a projekt obsahující akce společné pro obě služby (ServiceLib). Služby fungují pro klienta jako interface, přes který přistupuje k metodám, které jsou obsaženy v ServiceLib. Struktura implementace řešení služeb je dostupná v příloze B1. V implementaci jsem použil postupy pro tvorbu WCF služeb a klientů, které byly popsané v kapitole věnované tutoriálu. V rámci klienta RESTful služby jsem použil oba přístupy ke službě. Potřebné informace o klientském nastavení jsou ukládány do klientského konfiguračního souboru, který je budován mimo app.config s využitím možností .NET. V klientovi SOAP služby nevyužívám automatického generování proxy třídy a nastavení konfiguračního souboru pomocí ServiceReference. Místo toho jsem potřebné interface, třídy a konfigurace realizoval ručně v kódu klienta. Díky tomu jsem mohl mnohem lépe proniknout do vlastností a struktury klienta WCF služby. Implementace přístupu do databáze jsem definoval pomocí rozhraní IDBContract. Toto rozhraní používá abstraktní třída AbsDBContract. Tato abstrakní třída v sobě implementuje metody používané pro tvorbu SQL příkazů pro práci s jednotlivými tabulkami pro konkrétní operace. Tuto abstraktní třídu dědí třída DBContract. V ní jsem přepsal zbylé metody rozhraní, které nejsou v abstrakní třídě implementovány. Díky tomuto přístupu je možné snadno změnit databázový stroj, který se v rámci řešení projektů služeb využívá.

Obrázek 15 Návrh realizace přístupu k DB

Třídy reprezentující objekty, které jsem navrhl a použil pro komunikaci mezi klientem a službou jsou k nahlédnutí v příloze.

40


4.2.1 Databáze Pro ukládání informací o uživatelích, adresářích a souborech, jsem se rozhodl použít databázi SQLite. Tuto DB využívají služby výsledného řešení. Databáze SQLite je jednoduchá DB. Není závislá na instalaci databázového stroje na server. K celé databázi se přistupuje pomocí knihovny System.Data.SQLite.dll, která je součástí ADO.NET Data Provideru. SQLite Data Provider je pro .NET dostupný volně ke stažení. Toto řešení je výhodné z několika důvodů. Služba může být nasazena na různých strojích a nebude vyžadovat zajištění konkrétního databázového stroje do systému, kde služba běží. Pro rozsah dat, která se mají pro tento projekt zálohovat, je databáze nejen dostatečná, ale nabízí i novou zkušenost s jinou DB. Díky použití ADO.NET Data Provideru pro SQLite není přístup realizovaný pomocí objektově relačního mapování. Vzhledem k rozsahu databáze to však není problém. Databáze je složena ze tří tabulek. Tabulka users uchovává data o uživatelích a jejich rolích. Tabulka directories uchovává informace o adresářích a jejich relativních cestách vůči kořenovému adresáři pro webové služby. Tabulka files uchovává metadata souborů včetně ID adresáře, ve kterém se soubor nachází.

Obrázek 16 Datový model databáze

Pro práci s databází jsem se rozhodl použít program SQLite Administrator. V uživatelsky příjemném prostředí umožňuje tvorbu a editaci databáze včetně spouštění jednotlivých skriptů.

4.3 Nasazení Celkové řešení nasazení sestává ze dvou služeb běžících v rámci IIS 7.5 na virtuálním serveru s OS Windows Server 2008 R2. Server má svoji veřejnou IP adresu, přes kterou je připojen do veřejné sítě internet. K službám přistupuje uživatel přes internet pomocí klientské aplikace běžící na OS Windows.

41


Obrázek 17 Diagram nasazení celkového řešení

Webové služby jsou nasazeny na virtuálním serveru u společnosti ASPone. Adresa serveru je „ip-77-93-200-218.cust.aspone.cz“ s IP adresou 77.93.200.218. Nastavení IIS a certifikátů na serveru probíhalo podle tutoriálu z kapitoly 3.7. Přístup k jednotlivým službám je popsán v uživatelské příručce. Ta je součástí přílohy. Výsledná realizace klienta i služeb je dostupné na CD příloze jak ve formě publikovaných služeb, spustitelného programu a knihoven klienta, tak i ve formě celých řešení ve vývojovém prostředí Visual Studio 2008.

42


Testování

43

5 Testování

Kapitola 5 obsahuje popis průběhu mého ověřování funkčnosti řešení webové služby a jejího klienta. Při vývoji jsem použil unit testy. Otestoval jsem jimi vybrané metody vytváření SQL příkazů. Pro unit testování jsem užíval framework NUnit ve verzi 2.6. Vybrané testy jsou obsaženy v řešení webových služeb v rámci projektu Test.ServiceLib. Unit testování v této kapitole neuvádím. V průběhu implementace jsem průběžně testoval funkčnost díky možnostem Visual Studia 2008. To umožňuje snadné spuštění webových služeb přímo z vývojového prostředí. Díky tomu jsem mohl průběžně kontrolovat funkčnost služeb, klienta i vzájemnou komunikaci v rámci lokálního počítače.

5.1 Systémové testování Systémové testování jsem prováděl sám. Funkčnost webových služeb jsem ověřoval jak z lokálního systému, tak z nasazení na virtuálním serveru. Virtuální server je přístupný z internetu pomocí „ip-77-93-200218.cust.aspone.cz“. Pomocí programu Internet Explorer 9, spuštěného přímo ze serveru, jsem sledoval výpisy chybových hlášek webových služeb. Kódu chyb, jsem poté využil při hledání příčin problémů a řešení změny konfigurace IIS 7.5. Při testování komunikace klienta se službou na virtuálním serveru docházelo k problému s ověřením uživatele klientské aplikace. Tento problém byl způsoben 32 bitovou knihovnou System.Data.SQLite.dll. OS byl 64 bitový a aplikační pool IIS je nutné v tomto případě nastavit explicitně pro podporu i 32 bitových aplikací. V rámci lokálního testování problémy s nastavením IIS a OS nebyly. Pro lokální testování jsem měl k dispozici následují konfiguraci: 

notebook Acer Aspire 4820TG



procesor Intel Core i5 430M



operační paměť 4 GB



operační systém Windows 7



prohlížeč Internet Explorer 8



vývojové prostředí Visual Studio 2008

Testování

44



IIS 7.5



databázi SQLite

5.1.1 Nastavení připojení a přihlášení uživatele Postup Uživatel spustí aplikaci, v záložce Connection zvolí Set Configuration. V nově naběhlém okně vyplní Service Adress a Identity. Hodnoty jsou dostupné v uživatelské příručce. Volbu potvrdí tlačítkem Save. V záložce Connection zvolí Set Authentication. V nově naběhlém okně uživatel vyplní políčka Username a Password. Uživatel znovu potvrdí akci v dialogovém okně. Očekávaný výsledek Aplikace se připojí k webové službě na zvolené adrese. Naváže se šifrovaná komunikace pomocí certifikátu se zvolenou identitou. Proběhne automatická validace uživatele. Klientské aplikaci vrátí webová služba číslo reprezentující roli uživatele. Klientská aplikace podle role nastaví uživatelské prostředí. Výsledek Test proběhl v pořádku a s očekávaným výsledkem.

5.1.2 Volba vzdáleného adresáře Postup Uživatel, přihlášený z bodu 5.1.1 zvolí v menu Directories. Pro volbu adresáře úložiště zvolí Select Storage Directory. Při volbě adresáře úložiště vybere cestu k zvolenému adresáři. Volby potvrdí tlačítkem OK. Uživatel znovu potvrdí akci v dialogovém okně. Očekávaný výsledek Proběhne automatická validace uživatele. Aplikace nabídne volbu adresáře. Výpis aktuálně dostupných adresářů klient získá pomocí webové služby. Adresáře se načtou z databáze na serveru. Výsledek Test proběhl v pořádku a s očekávaným výsledkem.

45

Testování

5.1.3 Nahrání souboru na úložiště Postup Uživatel, přihlášený z bodu 5.1.1 se zvoleným pracovním adresářem podle bodu 5.1.2 úložiště zvolí soubor z levého okna aplikace. Odeslání souboru na server uživatel potvrdí stisknutím tlačítka Upload File. Uživatel znovu potvrdí akci v dialogovém okně. Očekávaný výsledek Aplikace naváže s webovou službou spojení. Proběhne automatická validace uživatele. Proběhne ověření role uživatele. Klientská aplikace nenabízí volby, které uživatel nemůže provádět. Proběhne přenos souboru do zvoleného adresáře úložiště. Výsledek Test proběhl v pořádku a s očekávaným výsledkem.

5.1.4 Stáhnutí souboru z úložiště Postup Uživatel, přihlášený z bodu 5.1.1 se zvoleným pracovním adresářem podle bodu 5.1.2 úložiště zvolí soubor z pravého okna aplikace. Stažení souboru z úložiště uživatel potvrdí stisknutím tlačítka Download File. Uživatel znovu potvrdí akci v dialogovém okně. Očekávaný výsledek Aplikace naváže s webovou službou spojení. Proběhne automatická validace uživatele. Proběhne přenos souboru do zvoleného lokálního adresáře. Výsledek Test proběhl v pořádku a s očekávaným výsledkem.

5.1.5 Smazání souboru z úložiště Postup Uživatel, přihlášený z bodu 5.1.1 se zvoleným pracovním adresářem podle bodu 5.1.2 úložiště zvolí soubor z pravého okna aplikace. Smazání souboru z úložiště uživatel potvrdí stisknutím tlačítka Delete File. Uživatel znovu potvrdí akci v dialogovém okně.

Testování

46

Očekávaný výsledek Aplikace naváže s webovou službou spojení. Proběhne automatická validace uživatele a ověření role uživatele. Proběhne mazání souboru z adresáře úložiště. Výsledek Test proběhl v pořádku a s očekávaným výsledkem.

5.2 Uživatelské testování Při tomto testování jsem požádal několik přátel, aby provedli jednotlivé kroky podle připraveného scénáře. Poté mě seznámili s postřehy a nedostatky, které objevili. Tím mi poskytli zpětnou vazbu s odstupem od vývoje. Některé připomínky jsem dodatečně zapracoval do výsledného řešení.

5.2.1 Scénář testu 1. Seznam se s uživatelskou příručkou. 2. Zapni klientskou aplikaci StorageClient. 3. Přihlas se ke službě jako uživatel admin, heslo admin1. 4. Proveď volbu adresáře na lokálním stroji i na úložišti. 5. Nahraj a stáhni soubor. 6. Vytvoř nový adresář na úložišti. 7. Smaž tento adresář. 8. Přidej nového uživatele úložiště. 9. Změň roli tomuto uživateli. 10. Smaž tohoto uživatele. 11. Proveď jakoukoli činnost. 12. Vypni klientskou aplikaci.

5.2.2 Test č. 1 Uživatel: Robert, 32 let, programátor C/C++. 

Při volbě adresáře úložiště je divné, že se zobrazuje „Select new directory“ a přitom si chci zvolit již existující adresář.



Místo tečky pro kořenový adresář bych dal lomítko.



U zadávání hesla při přidání uživatele jsou viditelné znaky hesla.



Bylo by fajn, kdyby mně aplikace nabídla existující uživatele pro editaci nebo smazání.

Testování

47



Zkusil jsem změnit heslo a nevím, jestli to bylo úspěšné.



Občas pomalé reakce aplikace.



Uživatelské rozhraní by mohlo být příjemnější. Nemám rád hodně potvrzovacích kliků myší.



Dobré je, že to má dvě okna. V tom je to lepší jak průzkumník.

5.2.3 Test č. 2 Uživatel Petra, 23 let, studentka ekonomie. 

U prvního bodu nevím, který exe soubor mám spustit.



Přenos většího souboru trvá hodně dlouho. Už jsem myslela, že se to rozbilo.



Při přidávání nové složky jsem nevěděla, co mám dělat.



Překvapilo mě, že pro mazání nepotřebuji zadat heslo.



Líbí se mi, že jsou tam okna s potvrzením. Díky tomu vím, že jsem neudělala chybu.



Musela bych se do toho víc vžít. Ovládání je komplikované.

5.2.4 Test č. 3 Uživatel Anna, 18 let, studentka gymnázia. 

Překvapilo mě, že při mazání uživatele nemusím zadávat heslo.



Chtěla bych, aby bylo možné přetahovat soubory mezi okny myší.



Mám raději česky psané popisy.

48

Testování

49

Závěr

6 Závěr

Zadání mé práce se skládalo z několika bodů a pokrývalo dvě technologie tvorby webových služeb. Mým cílem bylo zachytit vše potřebné pro realizaci webových služeb, pomocí Windows Communication Foundation 3.5, alespoň ve stručné podobě. Práci jsem strukturoval do několika oddílů. Po přečtení práce čtenář získá ucelený přehled o webových službách, jejich implementaci pomocí frameworku WCF 3.5 a nasazení na IIS. Žádný z mých zdrojů nepokrýval tento proces od teoretické části, přes implementaci, až do finálního nasazení včetně příkladu realizace jednotlivých úkonů. Doufám, že tato práce bude užitečným shrnutím všeho podstatného, s čím jsem se při řešení webových služeb pomocí WCF setkal. Jednotlivé kapitoly ilustrují postup ke splnění všech cílů bakalářské práce. V první části je obecné seznámení s platformou a popis webových služeb. Další kapitola se věnuje tutoriálu, ve kterém jsem popsal tvorbu webových služeb pomocí dvou architektur webových služeb. Jedná se o RPC SOAP a RESTful webové služby. V práci je porovnaný způsob realizace a návrhu služeb pomocí obou architektur. V závěrečných kapitolách popisuji můj návrh, řešení a testování úložiště souborů. Aplikace jsem realizoval na základě získaných zkušeností při psaní tutoriálu pro tvorbu webových služeb pomocí WCF. Výsledná webová služba je navržena pro ilustraci možností webových služeb a porovnání přístupů v jejich realizaci. Rozhraní poskytnuté webovou službou umožňuje nahrání, stažení, smazání souboru. Dále pak správu uživatelů, tvorbu adresářů, mazání adresářů. Implementovaný klient je pomocí WinForms a umožňuje přistupovat k veškeré funkcionalitě webové služby pomocí SOAP a k práci se soubory pomocí REST. Na základě testování uživateli mohu říct, že největší slabinou klientské aplikace je uživatelské rozhraní. Současnému uživateli nedopřává pohodlí, na které je zvyklý z profesionálních programů. Zároveň volba způsobu zabezpečení, neumožňuje přenos velkých souborů. Soubory v řádech desítek MB není vhodné přenášet pomocí výsledného řešení. Způsob šifrování celých zpráv jsem zvolil na základě doporučení pro nasazení webové služby ve veřejné síti internet podle [Meier a kol. 2008]. Tento postup je sice velmi bezpečný, ale náročnější na přenos většího množství dat. Práce pro mě byla velkým osobním přínosem. Nabídla mi možnost seznámit se s novými technologiemi a realizovat aplikaci od získání teoretických základů, až po

50

Závěr

výsledné nasazení v reálných podmínkách virtuálního serveru. Doposud jsem pracoval pouze s ASMX webovými službami. Byl jsem úplným nováčkem v oblasti WinForms aplikací. S technologií REST jsem se setkal při tvorbě bakalářské práce poprvé. Zároveň jsem neměl zkušenost s konfigurací IIS, správou uživatelů a práv v OS Windows Server 2008 R2. Díky nutnosti zvolit databázový stroj nezávislý na možnostech hostování jsem se seznámil s DB SQLite. V neposlední řadě jsem měl možnost vyzkoušet možnosti frameworku NUnit při realizaci unit testů. Velice si vážím všech nabytých zkušeností. Jak po stránce odborné, tak po stránce osobní. Pro zájemce o prohloubení znalostí v oblasti webových služeb pomocí WCF bych doporučil následující literaturu. [Lowy, 2007] pro RPC SOAP služby a [Flanders, 2008] pro RESTful webové služby. Obecné principy zabezpečení SOAP webových služeb jsou podrobně popsány v [Meier a kol., 2008].

6.1 Možnosti dalšího vývoje Současnou aplikaci by bylo možné rozšířit o několik funkcionalit, které by využily další možnosti frameworku .NET a rozšířily RESTful webové služby. RESTful webová služba by mohla být vzhledem k využití vlastního ověřování uživatele doplněna o interoceptor přijaté zprávy, který by zpracovával ověření uživatelského jména a hesla. Konfigurační soubor klientské aplikace by mohl nabízet custom řešení. Rozlišení rolí a identit uživatelů by mohlo umožnit ověření přístupu k jednotlivým adresářům nebo souborům. Obecně by se dalo rozšíření pojmout jako dodatečné navýšení funkcí samotné aplikace na základě již vybudovaného řešení. Podle výsledků testování by aplikace mohla být vylepšena o příjemnější GUI. V případě potřeby přenosu velkých souborů změněn způsob šifrování a přenosu zpráv.

51

Literatura

7 Literatura

BARNES, Jeff 2006. Metadata Exchange Endpoint [online]. [cit. 28.8.2011]. dostupné na: .

BLEWETT, Richard 2011. REST and .NET 3.5 Part 1 - why REST based services? [online]. [cit. 23.8.2011]. dostupné na: . CHEESO 2008. How to Build a REST app in .NET (with WCF) [online]. [cit. 23.8.2011]. dostupné na: . FLANDERS, Jon 2008. RESTful .NET. Sebastopol: O’Reilly. 310 p. ISBN 978-0-59651920-9. KALMAN, Patrick 2011a. Basic Authentication on a WCF REST Service [online]. [cit. 19.5.2012]. dostupné na: KALMAN, Patrick 2011b. Digest Authentication on a WCF REST Service [online]. [cit. 19.5.2012]. dostupné na: LOWY, Juval 2007. Programming WCF Services. Sebastopol: O’Reilly. 634 p. ISBN 0-596-52699-7. MCMURTRY, C.; MERCURI, M.; WATLING, N.; WINKLER, M. 2007. Windows Communication Foundation Unleashed. Indianapolis : Sams Publishing. 699 p. ISBN 0-672-32948-4.

52

Literatura

MEIER, J.D.; FARRE, C.; TAYLOR, J.; BANSODE, P.; GREGERSEN, S.; SUNDARARAJAN, M.; BOUCHER, R. 2008. Improving Web Services Security: Scenarios and Implementation Guidance for WCF [online]. [cit. 18.5.2012]. dostupné na: . RICHARDSON, L.; RUBY, S. 2007. RESTful Web Services. Sebastopol: O’Reilly. 454 p. ISBN 0-596-52926-0. SKONNARD, Aaron 2008. A Guide to Designing and Building RESTful Web Services with WCF 3.5 [online]. [cit. 17.5.2012]. dostupné na: . SKONNARD, Aaron 2009. A Developer‘s Guide to the WCF REST Starter Kit[online]. [cit. 18.5.2012]. dostupné na: .

53

Příloha A

Příloha A – Zdrojový kód tutoriálu

A1 Nastavení interface a jeho implementace v rámci třídy služby

[ServiceContract] public interface IService1 { [OperationContract] Stream GetFile(); } public class Service1 : IService1 { public Stream GetFile() { string filePath = "c:\\STM\\…\\pokus.txt"; if (!File.Exists(filePath)) { throw new FileNotFoundException("File was not found", Path.GetFileName(filePath)); } return new FileStream(filePath, FileMode.Open, FileAccess.Read); } }

54

Příloha A

A2 System.serviceModel ze souboru Web.config

<system.serviceModel> <services> <service name="FirstWcfService.Service1" behaviorConfiguration="FirstWcfService.Service1Behavior"> <endpoint address="" name="basicHttpStream" binding="basicHttpBinding" bindingConfiguration="httpLargeMessageStream" contract="FirstWcfService.IService1"> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> <serviceBehaviors> <serviceMetadata httpGetEnabled="true"/> <serviceDebug includeExceptionDetailInFaults="false"/>

55

A3 Implementace klienta služby class Client { static void Main(string[] args) { ServiceReference1.Service1Client service = new ServiceReference1.Service1Client(); Console.WriteLine("PRESS ENTER TO START CLIENT"); Console.ReadLine(); try { Stream input; input = service.GetFile(); FileStream output = new FileStream("c:\\STM\\...\\pokusVystup.txt", FileMode.Create, FileAccess.Write); WriteInputToOutput(input, output); output.Close(); input.Close(); Console.WriteLine("SUCCESS"); Console.ReadLine(); } catch {…} } public static void WriteInputToOutput(Stream input, Stream output) { const int bufferSize = 2048; byte[] buffer = new byte[bufferSize]; int bytes = 0; while ((bytes = input.Read(buffer, 0, bufferSize)) > 0) { output.Write(buffer, 0, bytes); } } }

Příloha A

56

Příloha A

57

Příloha B

Příloha B – Snímky struktury projektů

B1 Struktura řešení implementace služby

58

B2 Struktura řešení implementace klienta

Příloha B

Příloha C

59

Příloha C – Seznam použitých zkratek

ASMX

ASP.NET Webservices Source

ASP CLR

Common Language Runtime

GUI

Graphical User Interface

HTTP

Hypertext Trensfer Protocol

HTTPS

Hypertext Trensfer Protocol Secure

IIS

Internet Information Service

IPC

Inter Process Communication

JSON

JavaScript Object Notation

MEX

Metadata Exchange Endpoint

MMC

Microsoft Management Console

MSDN

Microsoft Developer Network

MSMQ

Message Queuing

MTOM

Message Transmission Optimization Mechanism

NTLM

NT Lan Manager

OS

Operační Systém

P2P

Peer To Peer

POX

Plain Old Xml

REST

Representational State Transfer

RFC

Request For Comments

RPC

Remote Procedure Call

SDK

Software Development Kit

SOA

Service Oriented Architecture

SOAP

Simple Object Access Protocol

SP

Service Pack

SSL

Secure Sockets Layer

TCP

Transmission Control Protocol

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

Příloha C

60

VS2008

Visual Studio 2008

WCF

Windows Communication Foundation

WS

Webová služba

WSDL

Web Service Definition Language

WWW

World Wide Web

XML

Extensible Markup Language

61

Příloha D – UML Diagramy

UC1 Soubory

Příloha D

62

UC2 Adresáře

Příloha D

63

UC3 Administrace uživatelů

UC4 Klientská Aplikace

Příloha D

64

Příloha D

Příloha E

65

Příloha E – Uživatelská a instalační příručka

Instalace programu Program je součástí přiloženého CD. Pro úspěšný chod aplikace je nutné mít všechny dodané soubory programu v jednom adresáři. Spustitelným souborem CoreApp.exe se program zapíná. Doporučené požadavky na běh programu vycházejí z požadavků na OS Windows 7 a jsou následující: 

OS Windows 7



Procesor s taktem min. 1GHz



Operační paměť min. 2GB



Prostor na pevném disku 1MB

Používání programu Program StorageClient slouží k přístupu k úložišti souborů, který je v období odevzdání a obhajoby této práce dostupný na „ip-77-93-200-218.cust.aspone.cz“. StorageClient umožňuje po ověření uživatele stahovat nahrané soubory z adresářů nahrávat soubory, tvořit a mazat adresáře na úložišti. Úložiště umožňuje práci se soubory pomocí RPC i RESTful webových služeb.

Základní popis uživatelského rozhraní Klientská aplikace je rozdělena na dvě části. V levé polovině se nachází výpis informací z úložiště a tlačítka umožňující provádět operace na úložišti. V pravé polovině je zpřístupněn výpis informací ze zvoleného lokálního umístění a tlačítka pro operace s lokálními soubory. Horní menu slouží pro nastavení konfigurace klientské aplikace, pro správu uživatelů úložiště a pro další volby. Podrobnější popis jednotlivých položek následuje níže.

Příloha E

66

Obrázek uživatelského rozhraní klientské aplikace

Menu Connection Pro úspěšné napojení na úložiště je nutné vyplnit přihlašovací údaje a umístění služby. Pro tento účel slouží položka horního menu Connection. 

Set Authentication slouží pro nastavení uživatelského jména a hesla, které je kontrolováno při využívání služby. Uživatel má nastavenou svou roli v rámci úložiště a podle ní mu jsou umožněny akce na úložišti.



Set Configuration je pro nastavení URI směřující ke koncovému bodu služby SOAP služby a RESTful služby. Upřesněné URI pro jednotlivé zdroje RESTful služby jsou budovány jako relativní cesta od přednastavené adresy RESTful webové služby.

RPC SOAP služba je dostupná na adrese: http://ip-77-93-200-218.cust.aspone.cz/WcfServiceSOAP/StorageService.svc RESTful služba je dostupná na adrese: http://ip-77-93-200-218.cust.aspone.cz/WcfServiceREST/Storage.svc Pro využití služby v módu SOAP je nutné nastavit identitu, použitou pro šifrování pomocí certifikátu. Identita: StorageCert Uživatelské jméno admin klient guest

Heslo

Role admin1 administrátor client1 klient guest1 host Tabulka přednastavených uživatelů, jejich hesel a rolí

Příloha E

67

Role administrátor má přístup k veškerým funkcím. Administrátor může zakládat a mazat nové uživatele. Zakládat adresáře a mazat adresáře prázdné. Stahovat soubory z úložiště a nahrávat soubory na úložiště. Má možnost si změnit své heslo. Role klienta má zamezené rozšířené možnosti administrace uživatelů a možnost mazání adresářů. Klient si může změnit v rámci administrace jen své heslo. Role hosta má umožněno pouze procházet úložiště, stahovat soubory a změnu svého hesla.

Menu Mode Volba mezi využitím RPC SOAP nebo RESTful webových služeb pro komunikaci s úložištěm. RESTful webová služba umožňuje pouze omezenou práci se soubory. Rozšířené možnosti administrace jsou umožněny jen v módu SOAP.

Menu Administration V menu administrace může uživatel, v roli administrátora, přidávat, mazat uživatele a případně měnit role uživatelů. Všechny role si mohou změnit své uživatelské heslo.

Menu Actions Toto menu obsahuje možnosti obsažené už od první verze klientské aplikace. Tyto volby zůstaly zachovány pro případ, kdy klient nechce měnit fixní volbu lokálního adresáře. Místo toho je možné pracovat v rámci celého lokálního stroje. 

Upload Any File umožňuje vybrat jakýkoli soubor z lokálního počítače a nahrát ho do zvoleného adresáře úložiště. Tato volba umožňuje pružné nahrání souboru bez ohledu na pevně zvolený lokální adresář pravé strany uživatelské aplikace Storage Client.



Download File Anywhere slouží pro stáhnutí vybraného souboru, z levé nabídky adresáře úložiště, kamkoli do lokálního počítače. Tato volba není opět vázána na zvolený lokální adresář pravé strany klientské aplikace.

Menu Directories Tato položka menu slouží k práci s adresáři na úložišti i pro volbu lokálního adresáře pro práci s úložištěm. 

Select Local Directory volí lokální adresář pro pravou stranu klientské aplikace. Tento adresář slouží pro stahování souborů z úložiště nebo jako zdroj souborů pro nahrání na úložiště.



Select Storage Directory volí z adresářů na úložišti ten, který se bude používat jako zdroj pro stahované soubory nebo místo uložení nahrávaných souborů z lokálního počítače.



Create New Storage Directory slouží pro založení nového adresáře na úložišti. Tato možnost v sobě zahrnuje volbu mateřského adresáře. Případně zvolit kořenový adresář reprezentovaný tečkou.

Příloha E

68



Delete Current Storage Directory je volbou, která slouží pro smazání již zvoleného adresáře úložiště z levé strany klientské aplikace. Smazání adresáře je možné pouze tehdy, je-li adresář prázdný.

Popis tlačítek dolní nabídky Tlačítka jsou rozdělena do levé a pravé poloviny. Levé půlka ovládá možnosti úložiště a pravá půlka možnosti lokálního stroje. 

Refresh aktualizuje stav ve zvoleném adresáři. Díky tomu je možné zjistit, jestli nedošlo ke změnám pomocí jiných programů nebo jiným uživatelem.



Delete maže zvolený soubor.



Download File stáhne zvolený soubor z vybraného adresáře úložiště do vybraného adresáře lokálního stroje.



Upload File nahraje vybraný soubor lokálního adresáře do zvoleného adresáře úložiště.

Popis dolní lišty V levé části dolní lišty se nachází informace o přihlášeném uživateli a vybraný mód webových služeb. V případě chybného ověření uživatele nebo jiného chybného nastavení je v tomto místě výzva pro změnu nastavení. V pravé části je jméno autora aplikace.

Řešení Problémů V případě problémů s připojením je doporučeno zkontrolovat správnost přihlašovacích údajů a nastavení umístění služeb včetně identity certifikátu. Pokud tím nejsou problémy odstraněny, nejčastěji pomůže nové nastavení přihlašovacích údajů nebo vypnutí a znovu zapnutí klientské aplikace. V případě přetrvávajících problémů, kontaktujte prosím autora aplikace.

Příloha F

69

Příloha F – Obsah přiloženého disku

Obsahem disku je tento text, projekty ve Visual Studiu 2008, opublikované výsledky a soubory pro spuštění klientské aplikace. Obsah přílohy na přiloženém disku je následující. 

ProjektKlient obsahuje řešení klientské aplikace ve Visual Studiu 2008.



ProjektSluzba obsahuje řešení webových služeb ve Visual Studiu 2008.



RESTfulService obsahuje publikované soubory RESTful webové služby.



SOAPService obsahuje publikované soubory RPC SOAP webové služby.



TextPrace obsahuje tento text bakalářské práce.



UML obsahuje diagramy a projekt v programu Enterprise Architect.



StorageClient obsahuje knihovny, spustitelný soubor a další soubory pro spuštění klientské aplikace.

Vedoucí práce: Ing. Martin Balík

Recommend Documents