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

Transkript

1

2 ii

3 Č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

4 iv

5 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.

6 vi

7 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

8 viii

9 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.

10 x

11 xi Obsah 1 Úvod Úvod do WCF a webových služeb Počátky Windows Communication Foundation Architektura WCF Architektura webových služeb RPC RESTful REST-RPC Hybrid Komunikace služeb Základní princip SOAP služeb Základní popis komunikace klienta se službou Porovnání SOAP s REST Zprávy SOAP a REST Tutoriál tvorby webových služeb pomocí WCF WCF služby obecně Volba Bindings Basic binding Web Service (WS) binding TCP binding Web binding Endpoints Metadata Exchange endpoint Contracts ServiceContract DataContract RPC SOAP WCF služba Konfigurační soubor RESTful služba... 20

12 xii HTTP metody a jejich použití Návrh RESTful služby URI šablony Tvorba interface Konfigurační soubor Zabezpečení služby Zabezpečení RPC SOAP služby Transport Security Message security Bindings a nastavení zabezpečení Ověření uživatele služby Příklad konfigurace služby Zabezpečení RESTful služby Hostování služby pomocí IIS Klient RPC SOAP webové služby Tvorba klienta pro WCF webovou službu pomocí Visual Studia Klient RESTful webové služby Návrh a realizace řešení souborového úložiště Specifikace a pokrytí požadavků Návrh řešení aplikace Databáze Nasazení Testování Systémové testování Nastavení připojení a přihlášení uživatele Volba vzdáleného adresáře Nahrání souboru na úložiště Stáhnutí souboru z úložiště Smazání souboru z úložiště Uživatelské testování Scénář testu Test č Test č

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

14 xiv

15 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] Obrázek 7 Koncový bod [Lowy, 2007] Obrázek 8 Nový projekt v programu Visual Studio Obrázek 9 Zabezpečení komunikace v rámci transportní vrstvy [Meier a kol., 2008] Obrázek 10 Zabezpečení komunikace pomocí šifrování zprávy [Meier a kol., 2008] Obrázek 11 Okno programu SelfCert Obrázek 12 Nastavení privátních klíčů pro certifikát v programu MMC Obrázek 13 Přidání aplikačního poolu mezi uživatele certifikátu Obrázek 14 Automatické přidání service reference ve VS Obrázek 15 Návrh realizace přístupu k DB Obrázek 16 Datový model databáze Obrázek 17 Diagram nasazení celkového řešení... 41

16 xvi

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

18 xviii

19 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 Výpis 6 Základní nastavení binding programově Výpis 7 Service Contract Výpis 8 Service Contract nastavení atributu Namespace Výpis 9 Operation Contract Výpis 10 Data Contract Výpis 11 Data Contract property Výpis 12 Definování a implementace ServiceContract Výpis 13 Nastavení readerquotas a dalších atributů pro wshttpbinding Výpis 14 Nastavení atributů WebGet a WebInvoke pro interface RESTful služby Výpis 15 Chování koncového bodu pro RESTful webovou službu Výpis 16 Nastavení zabezpečení v konfiguračním souboru Výpis 17 Nastavení certifikátu pro službu v konfiguračním souboru Výpis 18 Spuštění winhttpcertcfg.exe Výpis 19 WebChannelFactory pro klienta RESTful webové služby Výpis 20 HttpClient pro klienta RESTful webové služby... 35

20 xx

21 1 Úvod 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

22 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í.

23 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]

24 4 Úvod do WCF a webových služeb 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.

25 5 Úvod do WCF a webových služeb 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 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 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) 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: rch&tags=penguin Hybridní přístup se sice v praxi může objevovat, ale neodpovídá teorii REST.

26 6 Úvod do WCF a webových služeb 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] 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 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.

27 7 Úvod do WCF a webových služeb 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.

28 8 Úvod do WCF a webových služeb 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/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; MS Web Services Client Protocol ) VsDebuggerCausalityData: uidpo0szgn9vz1jnlbntu2dom+eaaaaaiynab7nab064unymh0nd+xl4qxc GfZhFgdOw31ajoK0ACQAA Content-Type: text/xml; charset=utf-8 SOAPAction: " moje.cz/iservice/datawrite" Host: :50942 Content-Length: 803 Expect: 100-continue Connection: Keep-Alive <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:body><datawrite xmlns=" <Data> 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/ OK Server: ASP.NET Development Server/ Date: Thu, 27 Jan :36:39 GMT X-AspNet-Version: Cache-Control: private Content-Type: text/xml; charset=utf-8 Content-Length: 343 Connection: Close <s:envelope xmlns:s="

29 9 Úvod do WCF a webových služeb <s:body xmlns:xsi=" xmlns:xsd=" <DataWriteResponse xmlns=" <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/ OK Content-Length: 1189 Content-Type: application/xml; charset=utf-8 Server: Microsoft-HTTPAPI/2.0 Date: Thu, 20 Mar :34:59 GMT <OrderInfoMsg > </OrderInfoMsg> 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.

30 10 Úvod do WCF a webových služeb

31 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 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 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 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 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,

32 12 Tutoriál tvorby webových služeb pomocí WCF bezpečnost apod. Optimalizuje komunikaci WCF s WCF. Je nutné, aby služba i klient podporovali WCF 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]

33 13 Tutoriál tvorby webových služeb pomocí WCF Je-li cílem vytvořit RESTful webovou službu, je volba snadná. Použije se vždy WebHttpBinding 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 = binding = wshttpbinding contract = MyNamespace.ImyContract /> </service> </services> </system.servicemodel> 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, " host.addserviceendpoint(typeof(imycontract),tcpbinding, "net.tcp://localhost:8001/myservice"); host.open( ); Výpis 6 Základní nastavení binding programově

34 14 Tutoriál tvorby webových služeb pomocí WCF 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 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 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ů 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.

35 15 Tutoriál tvorby webových služeb pomocí WCF [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 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.

36 16 Tutoriál tvorby webových služeb pomocí WCF [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.

37 17 Tutoriál tvorby webových služeb pomocí WCF 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.

38 18 Tutoriál tvorby webových služeb pomocí WCF [ServiceContract] public interface IService1 { [OperationContract] Stream GetFile(); } public class Service1 : IService1 { public Stream GetFile() { } } Výpis 12 Definování a implementace ServiceContract 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.

39 19 Tutoriál tvorby webových služeb pomocí WCF <bindings> <wshttpbinding> <binding name="custombinding" maxreceivedmessagesize=" " closetimeout="00:10:00" opentimeout="00:10:00" receivetimeout="00:10:00" sendtimeout="00:10:00" maxbufferpoolsize=" "> <readerquotas maxstringcontentlength=" " maxarraylength=" " maxbytesperread=" " maxnametablecharcount=" "/> </binding> </wshttpbinding> </bindings> Výpis 13 Nastavení readerquotas a dalších atributů pro wshttpbinding

40 20 Tutoriál tvorby webových služeb pomocí WCF 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] 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 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.

41 21 Tutoriál tvorby webových služeb pomocí WCF 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. Metoda URI šablona 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 users/{username}/friends/id editusersfriend DELETE users/{username}/friends/id 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 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.

42 22 Tutoriál tvorby webových služeb pomocí WCF [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 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. <behaviors> <endpointbehaviors> <behavior name="webhttp"> <webhttp /> </behavior> </endpointbehaviors> </behaviors> Výpis 15 Chování koncového bodu pro RESTful webovou službu

43 23 Tutoriál tvorby webových služeb pomocí WCF 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 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.

44 24 Tutoriál tvorby webových služeb pomocí WCF 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 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.

45 25 Tutoriál tvorby webových služeb pomocí WCF 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 basichttpbinding (přednastaveno) wshttpbinding nettcpbinding netpeertcpbinding netnamedpipebindi ng wsfederationhttpb inding (přednastaveno) (přednastaveno) (přednastaveno) wsdualhttpbinding X netmsmqbinding X (přednastaveno) (přednastaveno) X (přednastaveno) (přednastaveno) Tabulka 3 Možnosti zabezpečení podle zvoleného binding [Meier a kol., 2008] 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 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.

46 26 Tutoriál tvorby webových služeb pomocí WCF 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í 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. <bindings> <wshttpbinding> <binding name="custombinding" "> <security mode="message"> <message clientcredentialtype="username"/> </security> </binding> </wshttpbinding> </bindings> Výpis 16 Nastavení zabezpečení v konfiguračním souboru

47 27 Tutoriál tvorby webových služeb pomocí WCF 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. <behaviors> <servicebehaviors> <behavior name="namespace.mybehavior"> <servicecredentials> <servicecertificate findvalue="certificatename" storelocation="localmachine" storename="my" x509findtype="findbysubjectname" /> <usernameauthentication usernamepasswordvalidationmode="custom" customusernamepasswordvalidatortype= "Namespace.UserValidator, Namespace" /> </servicecredentials> </behavior> </servicebehaviors> </behaviors> 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í.

48 28 Tutoriál tvorby webových služeb pomocí WCF Hodnota Popis None Transport Výchozí nastavení. Koncový bod nebude vyžadovat žádný druh zabezpečení. Koncový bod bude vyžadovat SSL. TransportCredentialOnly 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] 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 None Basic Digest Ntlm Windows Certificate Výchozí nastavení. Žádné ověření není vyžadováno. Klient se musí prokázat použitím HTTP Basic authentifikačního protokolu (RFC 2617). Klient se musí prokázat použitím HTTP Digest authentifikačního protokolu (RFC 2617). Klient se musí prokázat použitím NTLM protokolu. Klient se musí prokázat pomocí Kerberos. V případě nemožnosti použití Kerberos se využije NTLM. Klient se musí prokázat platným certifikátem k serveru. Tabulka 5 Možnosti ověření klienta RESTful webové služby [Flanders, 2008] 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.

49 29 Tutoriál tvorby webových služeb pomocí WCF 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.

50 30 Tutoriál tvorby webových služeb pomocí WCF 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ů.

51 31 Tutoriál tvorby webových služeb pomocí WCF 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í.

52 32 Tutoriál tvorby webových služeb pomocí WCF 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 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.

53 33 Tutoriál tvorby webových služeb pomocí WCF 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ě.

54 34 Tutoriál tvorby webových služeb pomocí WCF 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<IMyRESTClient> cf = new WebChannelFactory<IMyRESTClient>(new Uri(" IMyRESTClient channel = cf.createchannel(); List<string> dirs = new List<string>(); try { } catch { } dirs = channel.listdirs(); 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.

55 35 Tutoriál tvorby webových služeb pomocí WCF HttpClient http = new HttpClient(" dir = "files/" + dirid.tostring(); Uri uri = new Uri(dir, UriKind.Relative); HttpResponseMessage resp = null; HttpContent content = null; try { } catch { } resp = http.get(uri); content = resp.content; DataContractSerializer ser = new DataContractSerializer(typeof(FileInformations)); FileInformations fis= (FileInformations)ser.ReadObject(content.ReadAsStream()); Výpis 20 HttpClient pro klienta RESTful webové služby

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

57 37 Návrh a realizace řešení souborového úložiště 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

58 38 Návrh a realizace řešení souborového úložiště 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ý

59 39 Návrh a realizace řešení souborového úložiště 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.

60 40 Návrh a realizace řešení souborového úložiště 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.

61 41 Návrh a realizace řešení souborového úložiště 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 cust.aspone.cz s IP adresou 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.

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

63 43 Testování 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 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 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

64 44 Testování IIS 7.5 databázi SQLite 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 Volba vzdáleného adresáře Postup Uživatel, přihlášený z bodu 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.

65 45 Testování Nahrání souboru na úložiště Postup Uživatel, přihlášený z bodu se zvoleným pracovním adresářem podle bodu ú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 Stáhnutí souboru z úložiště Postup Uživatel, přihlášený z bodu se zvoleným pracovním adresářem podle bodu ú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 Smazání souboru z úložiště Postup Uživatel, přihlášený z bodu se zvoleným pracovním adresářem podle bodu ú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ě.

66 46 Testování 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í 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 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í.

67 47 Testování 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 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é 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.

68 48 Testování

69 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

70 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.

71 51 Literatura 7 Literatura BARNES, Jeff Metadata Exchange Endpoint [online]. [cit ]. dostupné na: < BLEWETT, Richard REST and.net 3.5 Part 1 - why REST based services? [online]. [cit ]. dostupné na: < CHEESO How to Build a REST app in.net (with WCF) [online]. [cit ]. dostupné na: < FLANDERS, Jon RESTful.NET. Sebastopol: O Reilly. 310 p. ISBN KALMAN, Patrick 2011a. Basic Authentication on a WCF REST Service [online]. [cit ]. dostupné na: < Authentication-on-a-WCF-REST-Service> KALMAN, Patrick 2011b. Digest Authentication on a WCF REST Service [online]. [cit ]. dostupné na: < Authentication-on-a-WCF-REST-Service> LOWY, Juval Programming WCF Services. Sebastopol: O Reilly. 634 p. ISBN MCMURTRY, C.; MERCURI, M.; WATLING, N.; WINKLER, M Windows Communication Foundation Unleashed. Indianapolis : Sams Publishing. 699 p. ISBN

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

73 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); } }

74 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"> <identity> <dns value="localhost"/> </identity> </endpoint> <endpoint address="mex" binding="mexhttpbinding" contract="imetadataexchange" /> </service> </services> <behaviors> <servicebehaviors> <behavior name="firstwcfservice.service1behavior"> <servicemetadata httpgetenabled="true"/> <servicedebug includeexceptiondetailinfaults="false"/> </behavior> </servicebehaviors> </behaviors> <bindings> <basichttpbinding> <binding name="httplargemessagestream" maxreceivedmessagesize=" " transfermode="streamed" messageencoding="mtom" /> </basichttpbinding> </bindings> </system.servicemodel>

75 55 Příloha A 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); } } }

76 56 Příloha A

77 57 Příloha B Příloha B Snímky struktury projektů B1 Struktura řešení implementace služby

78 58 Příloha B B2 Struktura řešení implementace klienta

79 59 Příloha C Příloha C Seznam použitých zkratek ASMX ASP CLR GUI HTTP HTTPS IIS IPC JSON MEX MMC MSDN MSMQ MTOM NTLM OS P2P POX REST RFC RPC SDK SOA SOAP SP SSL TCP URI URL ASP.NET Webservices Source Common Language Runtime Graphical User Interface Hypertext Trensfer Protocol Hypertext Trensfer Protocol Secure Internet Information Service Inter Process Communication JavaScript Object Notation Metadata Exchange Endpoint Microsoft Management Console Microsoft Developer Network Message Queuing Message Transmission Optimization Mechanism NT Lan Manager Operační Systém Peer To Peer Plain Old Xml Representational State Transfer Request For Comments Remote Procedure Call Software Development Kit Service Oriented Architecture Simple Object Access Protocol Service Pack Secure Sockets Layer Transmission Control Protocol Uniform Resource Identifier Uniform Resource Locator

80 60 Příloha C 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

81 61 Příloha D Příloha D UML Diagramy UC1 Soubory

82 62 Příloha D UC2 Adresáře

83 63 Příloha D UC3 Administrace uživatelů UC4 Klientská Aplikace

84 64 Příloha D

85 65 Příloha E 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 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.

86 66 Příloha E 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: RESTful služba je dostupná na adrese: 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 Heslo Role admin admin1 administrátor klient client1 klient guest guest1 host Tabulka přednastavených uživatelů, jejich hesel a rolí