eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Vytvo°ení rozhraní pro MS Exchange formou web service pro IIS server
Petr Dousek
Vedoucí práce:
Ing. Pavel Náplava
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
25. kv¥tna 2011
iv
v
Pod¥kování D¥kuji vedoucímu bakalá°ské práce Ing. Pavlu Náplavovi za poskytnutí cenných rad a p°ipomínek nutných k vypracování této bakalá°ské práce.
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 Praze dne 25.5.2011
.............................................................
viii
Abstract The theoretical part of this bachelor's thesis analyzes and evaluates application programming interface of Microsoft Exchange server and the practical part is aimed at implementation of web service for Microsoft Exchange server and ligthweigth user interface for this web service. This bachelor's thesis has two main parts. The rst part is aimed at anlyzing and evaluating Microsoft Exchange server's application programming interface. In this part I also desing a web service which uses previously mentioned API to connect and manage items stored at Microsoft Exchange server. In the second, I describe implementation of above mentioned web service. Furthermore, I decsribe implementation of lightweigth web user interface which uses the web service for connecting to MS Exchange server. I oer some possible extensions of this web service and of it's user interface at the end of this thesis. Keywords: Microsoft, Exchange, web service, application programming interface, Exchange Web Services
Abstrakt Zám¥rem této bakalá°ské práce je z teoretického hlediska analýza aplika£ního rozhraní Microsoft Exchange serveru, praktická £ást se zabývá implementací webové sluºby pro Microsoft Exchange server a implementací odleh£eného uºivatelského rozhraní, které bude tuto sluºbu vyuºívat. Tato práce je rozd¥lena do dvou hlavních £ástí. V první £ásti se zabývám zhodnocením výchozího stavu Microsoft Exchange serveru, analýzou jeho aplika£ního rozhraní a návrhem webové sluºby, která bude vyuºívat toto aplika£ní rozhraní vyuºívat k p°ístupu k prost°edk·m serveru. V druhé £ásti se zabývám implementací této webové sluºby podle ix
x poºadavk· speci kovaných vý²e. Dále je zde popsána implementace odleh£eného webového rozhraní, které tuto sluºbu vyuºívá k napojení na MS Exchange server. V záv¥ru práce nabízím n¥kolik moºných roz²í°ení této webové sluºby i jejího uºivatelského rozhraní. Klí£ová slova: Microsoft, Exchange, webová sluºba, aplika£ní rozhraní, Exchange Web Services
Obsah 1
Úvod
2
Analýza sou£asného stavu
3
3
Analýza a návrh °e²ení
7
4
Realizace
5
Testování a zhodnocení implementované funkcionality
1.1 1.2 1.3 1.4
Cíle projektu . . . . . . . . Sou£asný stav . . . . . . . . Speci kace projektu . . . . Struktura bakalá°ské práce .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2.1 Popis °e²eného problému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Aplika£ní rozhraní Microsoft Exchange Web Services . . . . . . . . . . . . . . 2.3 Aplikace vyuºívající Microsoft Exchange server . . . . . . . . . . . . . . . . . 3.1 3.2 3.3 3.4
4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12
Implementa£ní moºnosti . . . . . . . . Analýza poºadavk· na webovou sluºbu Analýza webové sluºby . . . . . . . . . Analýza webového rozhraní . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
P°ípravná fáze . . . . . . . . . . . . . . . . . . . . . . Poznámka . . . . . . . . . . . . . . . . . . . . . . . . . Implementace datových hierarchií ExItem a Response Základ webové sluºby . . . . . . . . . . . . . . . . . . Základ webového rozhraní . . . . . . . . . . . . . . . . Realizace p°ihla²ování . . . . . . . . . . . . . . . . . . Vytvá°ení poloºek . . . . . . . . . . . . . . . . . . . . . Získávání poloºek . . . . . . . . . . . . . . . . . . . . . Úprava a mazání poloºek . . . . . . . . . . . . . . . . . Roz²i°itelnost webové sluºby . . . . . . . . . . . . . . . Realizace klientské aplikace . . . . . . . . . . . . . . . Komponenty uºivatelského rozhraní . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
1
1 1 2 2 3 3 5
. 7 . 8 . 9 . 10 . . . . . . . . . . . .
15
15 15 16 17 18 19 20 20 21 22 22 23
25
5.1 Testování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2 Zhodnocení implementované funkcionality . . . . . . . . . . . . . . . . . . . . 25 xi
xii 6
OBSAH
Záv¥r
27
6.1 Napln¥ní cíl· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.2 Moºnosti dal²ího vývoje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
A Seznam pouºitých zkratek
31
B Instala£ní a uºivatelská p°íru£ka
33
C Obsah p°iloºeného CD
35
Seznam obrázk· 2.1 Schéma interakcí mezi MSE serverem a klientskými aplikacemi[11] . . . . . . 3.1 3.2 3.3 3.4
UML diagram návrhového vzoru Adapter Diagram t°íd pro hierarchii ExItem . . . . Diagram t°íd pro hierarchii Response . . . Návrhový vzor proxy . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
4 10 11 11 12
4.1 Schéma testovacího prost°edí . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
xiii
xiv
SEZNAM OBRÁZK
Kapitola 1
Úvod 1.1 Cíle projektu Základním stavebním prvkem této práce je vytvo°ení webové sluºby pro Microsoft Exchange server[13] (dále jen 'MSE'), která bude umoº¬ovat pohodlnou moºnost p°ístupu k poloºkám na MSE. Tato webová sluºba usnadní vývojá°i klientské aplikace napojeni MSE a základní práci s poloºkami typu Po²ta, Kalendá°, Úkol a Kontakt. Dále mu poskytne solidní základ, který je velice snadné upravit pro pot°eby nov¥ vyvíjeného produktu. Vzhledem k tomu, ºe webové sluºby jsou p°ed zraky b¥ºného uºivatele internetu skryty (ne snad proto, ºe by je b¥ºný uºivatel nevyuºíval/nepot°eboval, ale spí²e proto, ºe si jejich existenci neuv¥domuje) je p°edpokládaným uºivatelem této práce vývojá° webové/klientské aplikace pracující na integraci funkcionality MSE do jiº existující remní infrastruktury. Sou£ástí této práce je i ukázková aplikace, na které demonstruji moºnosti této webové sluºby. Z d·vodu existence knihovny Microsoft Exchange Web Services[10], která °e²í velkou £ást zadání této práce, jsme se po dohod¥ s vedoucím práce ing. Náplavou dohodli na roz²í°ení p·vodního zadaní o implementaci webového rozhraní, které bude vyuºívat webovou sluºbu implementovanou v rámci této práce.
1.2 Sou£asný stav V sou£asné dob¥ je ze strany výrobce MSE (spole£nosti Microsoft Corporation) podporováno n¥kolik API1 pro p°ístup k prost°edk·m MSE. Primárním protokolem je proprietární RPC/MAPI2 , který vyuºívají nap°íklad MS Outlook nebo Novell Evolution[4]. Dal²í moºností bylo d°íve pouºití protokolu WebDAV3 , které bylo ve verzi MSE 2007 nahrazeno rozhraním Exchange Web Services (dále jen 'EWS') a od verze MSE 2010 není dále podporováno. Nejnov¥j²ím rozhraním je EWS, které je zaloºeno na protokolu SOAP4 a oproti d°íve pouºívanému protokolu WebDAV usnad¬uje komunikaci mezi klientem a serverem. Dal²í výhodou Application Programming Interface Remote Procedure Call, Messaging API 3 Web-based Distributed Authoring and Versioning 4 Simple Object Access Protocol - protokol, pro vým¥nu objekt· p°es po£íta£ovou sí´ zaloºený na jazyku XML 1 2
1
2
KAPITOLA 1.
ÚVOD
pouºití tohoto protokolu je zkrácení £asu synchronizace oproti pouºití WebDAVu. EWS je obdobn¥ jako RPC/MAPI proprietárním °e²ením spole£nosti Microsoft, je ale voln¥ dostupné ke staºení a jeho podrobná dokumentace (v£etn¥ p°íklad·) je dostupná na MSDN5 . Samoz°ejmostí je i podpora ²iroce roz²í°ených protokol· pro vým¥nu po²ty POP, IMAP a SMTP6 .
1.3 Speci kace projektu Hlavním cílem tohoto projektu je usnadnit vývojá°·m práci p°i integraci funkcí MSE do jejich projekt·. I p°esto, ºe Microsoft ud¥lal velký kus práce za vývojá°e tím, ºe poskytl dobré (a dob°e dokumentované!) API pro MSE, stále je struktura relativn¥ sloºitá a navíc jej nelze pouºít p°ímo v n¥kterých projektech7 . T¥ºi²t¥m funkcionality této webové sluºby jsou CRUD8 operace s poloºkami typu Po²ta, Kalendá°, Úkol a Kontakt. Cílem této práce není poskytnout v rámci webové sluºby kompletní funkcionalitu MSE (coº by byla do jisté míry práce zbyte£ná, protoºe tuto funkcionalitu nabízí MS OWA9 ). Cílem je vytvo°it webovou sluºbu, která bude poskytovat odleh£enou funkcionalitu MSE a bude umoº¬ovat jednoduchou roz²i°itelnost o p·vodn¥ neposkytované funkce a parametry. D·leºitou vlastností je také kompletní odstín¥ní klientské aplikace od EWS a MSE. Díky tomuto odstín¥ní nám vzniká t°ívrstvá aplikace, kde datový model (MSE), bussiness logika (webová sluºba) a prezenta£ní vrstva (klientssá aplikace) jsou vzájemn¥ nezávislé. Druhým cílem je vytvo°ení uºivatelsky p°ív¥tivého, odleh£eného webového rozhraní, které bude tuto webovou sluºbu vyuºívat. Toto rozhraní bude umoº¬ovat základní správu v²ech typ· poloºek, které poskytuje vý²e zmi¬ovaná webová sluºba a také vylep²enou podporu kalendá°e, jehoº implementace MS Outlooku je pon¥kud ne²tastná.
1.4 Struktura bakalá°ské práce Tato práce je strukturována do kapitol, jejichº obsah je ve stru£nosti shrnut dále. Následující, 2., kapitola se zabývá sou£asnými aplikacemi, které m·ºeme vyuºít pro p°ipojení k MSE. V této kapitole také rozebírám jednotlivá API, které MSE poskytuje pro klientské aplikace. Ve 3. kapitole se zabývám analýzou a návrhem webové sluºby, která byla popsána d°íve v této kapitole. 3. kapitola také obsahuje moºné alternativní °e²ení díl£ích problém· spojených s návrhem této webové sluºby. Obsahem 4. kapitoly je implementace webové sluºby podle zadání práce s vyuºitím analýzy provedené ve 3. kapitole. V 5. kapitole se zabývám analýzou, návrhem a popisem implementace odleh£eného webového rozhraní pro MSE. V záv¥re£né 6. kapitole shrnuji dosaºené výsledky práce a nabízím n¥kolik moºných vylep²ení projektu. V p°ílohách jsou obsaºeny instrukce pro instalaci, obsah p°iloºeného CD a seznam pouºitých zkratek. Z d·vodu pouºití velkého mnoºství zkratek jsem se rozhodl, ºe kaºdou zkratku vysv¥tlit v poznámce pod £arou a zárove¬ uvádím kompletní seznam pouºitých zkratek v záv¥ru práce. Microsoft Developer Network Post O ce Protocol, Internet Message Access Protocol, Simple Mail Transfer Protocol 7 Nap°íklad ho nem·ºeme vyuºít v MS Silverlight 4 aplikaci, protoºe nepodporuje p°idání dynamicky linkovaných knihoven (*.dll) 8 Create, Retrieve, Update, Delete 9 Outlook Webb App 5 6
Kapitola 2
Analýza sou£asného stavu 2.1 Popis °e²eného problému Jedním z významných faktor·, které ovliv¬ují chod a efektivitu st°edn¥ velkých a velkých podnik· je efektivnost vnitropodnikové komunikace. Tato komunikace m·ºe mít mnoho r·zných forem od komunikace osobní, p°es telefonickou aº po komunikaci elektronickou. A práv¥ význam elektronické komunikace se v sou£asné dob¥ je²t¥ více prohlubuje. S rostoucím významem elektronické komunikace investuje mnoho podnik· do budování vlastní IT infrastruktury za ú£elem podpory komunikace. Základním stavebním kamenem takové infrastruktury je bezesporu server pro správu elektronické po²ty - email·. Naprostou v¥t²inu trhu (více neº 85 %[6]) s emailovými servery ovládají sendmail, MSE, Post x a Exim. Zajímavým faktem je, ºe jediným £ist¥ proprietárním °e²ením je MSE, který je dodáván v rámci licen£ních podmínek MS CAL1 . V²echny ostatní emailové servery jsou poskytovány zdarma, sendmail2 a Post x v rámci vlastních otev°ených licencí, Exim v rámci GNU/GPL3 licence. Výhodou placeného MSE oproti jeho konkurenci je komplexní správa nejen emailových zpráv, ale i dal²ích organiza£ních a plánovacích funkcí jako jsou kalendá°e, úkoly a kontakty. MSE také t¥ºí z velké provázanosti s MS Windows Server infrastrukturou, ze které vyuºívá sluºby Domain Controlleru, Active Directory a dal²ích. Tato pom¥rn¥ vysoká míra závislosti na dal²ích komponentách omezuje moºnost instalace MSE pouze na opera£ní systémy rodiny MS Windows Server.
2.2 Aplika£ní rozhraní Microsoft Exchange Web Services EWS je API pro p°ístup a správu poloºek na MSE serveru verze 2007 a nov¥j²ích verzí. Bylo uvedeno spole£n¥ s MSE 2007 a od verze MSE 2010 nahrazuje d°íve podporovaný protokol WebDAV, který jiº není dále podporován. EWS jsou poskytovány zdarma jako dynamicky linkovaná knihovna (p°idat odkaz na stazeni). Velkou výhodou tohoto API je i kvalitní dokumentace dostupná online na MSDN4 . Obrázek 2.1 znázor¬uje schéma interakcí mezi EWS Microsoft Client Access License ve verzi pro serverové produkty sendmail existuje v Open Source i v propritární verzi 3 GNU General Public Licence 4 Microsoft Developer Network[12] 1 2
3
4
KAPITOLA 2.
ANALÝZA SOUASNÉHO STAVU
Obrázek 2.1: Schéma interakcí mezi MSE serverem a klientskými aplikacemi[11]
a klientskými aplikacemi. EWS odsti¬uje vývojá°e webové sluºby/klientské aplikace od MSE, protokol· pro p°enos dat p°es sí´ (TCP5 /UDP6 ) a nabízí pln¥ objektový p°ístup k °e²ení problému. Tento p°ístup je pro vývojá°e velice pohodlný a p°ipojení k MSE se sloºitostí blíºí nap°íklad otev°ení lokálního souboru. EWS podporují dva typy p°ihlá²ení. Prvním z nich je p°ihlá²ení za pouºití lokálního ú£tu na klientském po£íta£i7 nebo pomocí tzv. 'WebCredentials'. WebCredentials Transmission Control Protocol User Datagram Protocol 7 Podobn¥ jako MS Outlook pouºijí jméno a heslo práv¥ p°ihlá²eného uºivatele, coº je vhodné u do domény 5 6
2.3.
APLIKACE VYUÍVAJÍCÍ MICROSOFT EXCHANGE SERVER
5
je p°ihla²ování za pomoci manuáln¥ zadaného jména a hesla - tento zp·sob budu vyuºívat pro p°ihla²ování p°es webovou sluºbu. D·leºitou vlastností je také ²ifrování spojení mezi EWS a MSE za pomoci protokolu SSL8 . V této knihovn¥ jsou obsaºeny namespacy Microsoft.Exchange.WebServices.Autodiscover, Microsoft.Exchange.WebServices.Dns a Microsoft.Exchange.WebServices.Data. Z t¥chto namespac· je nejd·leºit¥j²í ten poslední jmenovaný. Namespace Microsoft.Exchange.WebServices.Data obsahuje (mimo mnoho dal²ích) abstraktní t°ídu ServiceObject obsahující základní vlastnosti, které zd¥dí v²echny typy poloºek, se kterými bude navrhovaná webová sluºba pracovat. D·leºitými vlastnostmi této t°ídy jsou Service typu ExchangeService a Schema typu ServiceObjectSchema. ExchangeService je t°ída zaji²´ující napojení na MSE server - tzn. obsahuje p°ihla²ovací údaje uºivatele, adresu EWS9 a dal²í (pro ú£ely navrhované webové sluºby) mén¥ d·leºité vlastnosti. Abstraktní t°ída ServiceObjectSchema bude dále zd¥d¥na pro kaºdý typ poloºky. U jednotlivých poloºek bude obsahovat seznam dostupných parametr· pro danou poloºku. Od t°ídy Service je odd¥d¥na t°ída Item, která spole£ným p°edkem pro v²echny ostatní typy poloºek, které bude navrhovaná webová sluºba obsluhovat. T°ída Item obsahuje základní vlastnosti, jako jsou Body, Subject a Attachements. Po dal²ím d¥d¥ní se dostaneme jiº dostaneme k jednotlivým typ·m poloºek. Jsou to t°ídy EmailMessage, Appointment10 , Task a Contact. Posledními t°ídami, které zmíním jsou ItemView a FindItemResults11 (a její potomci). Tyto t°ídy jsou d·leºité pro vyhledávání poloºek na MSE serveru, pro které neznáme jejich ID. V rámci ItemView m·ºeme za pomoci p°íslu²ných t°íd z hierarchie ServiceObjectSchema speci kovat, které vlastnosti vyhledávaných objekt· chceme získat (a sníºit tak zatíºení sít¥). Pomocí metody FindItems12 s parametry parentFolderId13 a ItemView. Návratovým typem metody FindItems je generická t°ída FindItemResults
- .
2.3 Aplikace vyuºívající Microsoft Exchange server Obdobným platformním omezením jako MSE trpí i klientské aplikace pro p°ístup k poloºkám na MSE a jejich správu. Nejlépe propracovanou aplikací a podporovanou aplikací je MS Outlook, jehoº cílovou platformou jsou opera£ní systémy rodiny MS Windows a Apple Mac OS14 . Dal²ími klienty podporujícími protokol MAPI/RPC jsou Novell Evolution, Mozilla Thunderbird, SquirellMail a The Bat!. Podpora funkcí u t¥chto 'alternativních' klient· bohuºel nedosahuje kvality MS Outlooku, který z·stává daleko p°ed konkurencí15 . p°ipojených po£íta£· a desktopových aplikací, ale pro ú£ely webové sluºby je zcela nepouºitelné 8 Secured Socket Layer 9 EWS je v tomto kontextu sluºba spu²t¥ná na MSE serveru, která zaji²´uje spojení webové sluºby a MSE serveru 10 T°ída Appointment nahrazuje CalendarItemType z EWS verze 1.0 11 Exituje i varianta FindFolderResults pro vyhledávání adresá°·, její pouºití je obdobné 12 Metoda FindItems náleºí (trochu nelogicky) t°íd¥ ExchangeService 13 Pro zji²t¥ní ID základních adresá°· uºivatele lze vyuºít t°ídu WellKnownFolderName 14 Mac OS není primární platformou pro MS O ce a nemusí podporovat ve²keré funkce MS Outlooku pro MS Windows 15 Toto porovnání vychází z p°edpokladu, ºe chceme pouºívat ve²keré funkce MSE. Pokud bysme cht¥li vyuºívat MSE 'pouze' jako emailový server, potom máme moºnost pouºít jakéhokoli klienta s podporou
6
protokol· POP3/IMAP a SMTP.
KAPITOLA 2.
ANALÝZA SOUASNÉHO STAVU
Kapitola 3
Analýza a návrh °e²ení 3.1 Implementa£ní moºnosti V následujícím textu jsou uvád¥ny jen technologie spole£nosti MS. Toto omezení vyplývá ze snahy o technologickou jednotnost celého systému1 . Dal²ím d·vodem je snaha o osobní rozvoj (pochopení a vyuºití platformy MS .NET framework a jazyka C#). V¥°ím, ºe podobného výsledku je moºné dosáhnout i za pouºití platformy Java spole£nosti Oracle nebo mnoha jiných, ale z vý²e zmín¥ných d·vod· jsem tyto technologie opomenul. Jak jiº bylo zmín¥no vý²e, hlavním cílem této práce je vytvo°it webovou sluºbu pro zp°ístupn¥ní poloºek uloºených na MSE serveru klientským aplikacím. Vyuºití konceptu webových sluºeb pro napojení na MSE je velmi výhodné, protoºe ú£elem webových sluºeb je práv¥ zp°ístup¬ování zdroj· dostupných v síti Internet webovým aplikacím. Webové sluºby nám tímto zp·sobem usnad¬ují vytvá°ení sloºitých webových aplikací, které se nemusejí (v tak velké mí°e) zabývat bussiness logikou, ale spí²e vlastní prezentací a zp°ístupn¥ním obsahu. Také nám umoº¬ují snadnou roz²i°itelnost jiº existujících aplikací, obzvlá²t¥ v p°ípad¥, ºe jednotlivé sluºby poskytující obsah dané aplikaci implementují stejné rozhraní. V na²em p°ípad¥ by takovou sluºbou mohla být nap°íklad sluºba, která bude poskytovat p°ipojení k mailserveru pomocí protokolu IMAP/SMTP, díky £emuº bysme získali mnohem univerzáln¥ji pouºitelného klienta bez nutnosti velkých zásah· do jeho zdrojového kódu. Dal²ím °e²ení tohoto problému by mohlo být vytvo°ení knihovny funkcí, která by poskytovala podobnou funk£nost. Toto °e²ení by m¥lo n¥kolik velkých výhod, ale i nevýhod. Nejspí²e nejv¥t²í výhodou vyuºití knihovny funkcí místo webové sluºby by bylo zna£né zefektivn¥ní a zrychlení komunikace. D·vodem tohoto zrychlení by bylo zpracování odpov¥di MSE p°ímo na stran¥ klienta bez nutnosti odpov¥¤ znovu serializovat a posílat po pomalé síti zp¥t klientovi. Naopak nevýhodami tohoto °e²ení je náro£n¥j²í pouºití v rámci webové aplikace2 a výrazn¥ obtíºn¥j²í aktualizace knihovny na stran¥ klienta (z d·vodu aktualizace a roz²í°ení). MS Windows Server 2008 R2, MSE, MS Internet Information Services jsou nutnými komponentami vyplývajícími ze zadaní práce 2 Nap°íklad MS Silverlight nepodporuje dynamicky linkované knihovny kompilované do Common Language Runtime (CLR), ale jen vlastní verzi t¥chto knihoven, které jsou kompilovány do mini-CLR. mini-CLR je podmnoºinou CLR a proto je moºné tyto 'o°ezané' knihovny vyuºívat v desktopových aplikacích. 1
7
8
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Z vý²e uvedených d·vod· je z°ejmé, ºe pro tvorbu webových aplikací je vhodn¥j²í vytvo°it a dále vyuºívat webovou sluºbu. Pro desktopové aplikace m·ºeme úsp¥²n¥ a snadno vyuºívat ob¥ moºnosti s ohledem na poºadavky na implementovaný systém. Druhým cílem této práce je implementace webového rozhraní. Zde máme k dispozici dv¥ hlavní technologie ASP3 .NET a Silverlight. ASP.NET je ur£eno pro tvorbu webových aplikací, které jsou zaloºeny na komunikaci se serverem. Server v tomto p°ípad¥ provádí poºadavky od klienta (v na²em p°ípad¥ by vysílal poºadavky a zpracovával odpov¥di od webové sluºby) a zp¥t odesílá kompletní webové stránky, které klient pouze zobrazí v prohlíºe£i. Moºným roz²í°ením je pouºití AJAXu4 pro skriptování na stran¥ klienta. Výhodou je nezávislost na platform¥ klienta (jedinou podmínkou je pouºití moderního webového prohlíºe£e). Nevýhodou je nutnost vºdy skriptovat na stran¥ serveru, coº m·ºe vést k jeho p°etíºení a zhor²ení odezvy celého systému. Druhou zmi¬ovanou technologií je MS Silverlight. Silverlight je aplika£ní framework pro tvorbu webových aplikací s podobnou funk£ností jakou nabízí Adobe Flash. Aplikace vytvo°ená v Silverlightu je po staºení do klientského po£íta£e m·ºe být nezávislá na serveru (aplikace je spu²t¥na u klienta v prohlíºe£i, ale m·ºe vysílat poºadavky zdroj·m dostupným v síti). Výhodou tedy je men²í zát¥º serveru a urychlení komunikace se sí´ovými zdroji (nap°íklad s webovými sluºbami). Zna£nou nevýhodou této technologie (a spu²t¥ní aplikací v prohlíºe£i obecn¥) je nutnost instalace pluginu pro spu²t¥ní aplikace na klientském po£íta£i. Silverlight je v sou£asné dob¥ podporován na platformách MS Windows, MS Windows Phone 7, Apple Mac OS X a Symbian OS. O ciální podpora pro opera£ní systémy z rodiny UNIX (Linux, Oracle Solaris a jiné) zatím neexistuje a z°ejm¥ jedinou moºností, jak na t¥chto opera£ních systémech spustit aplikace v Silverlightu je vyuºít neo ciální runtime Novell Moonlight5 . Také výkon t¥chto aplikací je v porovnání se srovnatelnými desktopovými aplikacemi niº²í a mohou zp·sobovat pády a 'mrznutí' prohlíºe£e6 . Pro implementaci webového rozhraní jsem si vybral technologii MS Silverlight, protoºe umoº¬uje b¥h aplikace na stran¥ klienta a proto, ºe implementace webového rozhraní se blíºí implementaci desktopové aplikace.
3.2 Analýza poºadavk· na webovou sluºbu V¥t²ina funk£ních poºadavk· vychází ze zadání této práce: • Sluºba bude poskytovat CRUD operace pro poloºky typu Po²ta, Kalendá°, Úkol a Kon-
takt
• Sluºba bude poskytovat adresá°e v emailové schránce uºivatele • Sluºba bude poskytovat hromadné operace s hlavi£kami emailových zpráv • Sluºba bude poskytovat hromadné operace s poloºkami podporovaných typ· Active Server Pages Asynchronous JavaScript and XML 5 Moonlight je zaloºen na projektu Mono (Open source implementace MS .NET frameworku pro UNIXové opera£ní systémy) a v sou£asné dob¥ nepodporuje Silverlight 4 aplikace. Také má problémy se stabilitou a výkonem. 6 Typickým p°íkladem je nestabilita a nízký výkon jiº d°íve zmi¬ovaného Adobe Flash Playeru, zejména mimo platformu MS Windows 3 4
3.3.
ANALÝZA WEBOVÉ SLUBY
9
• Sluºba bude poskytovat zabezpe£ené p°ipojení k MSE • Sluºba bude vyuºívat standardní p°ihla²ovací mechanismu pro p°ihlá²ení z webové
aplikace
• Sluºba bude odsti¬ovat klientskou aplikaci od logiky a typ· MSE serveru
Z d·vodu zam¥°ení webové sluºby na odleh£ená webová rozhraní pro MSE a po dohod¥ s vedoucím práce jsem se rozhodl neimplementovat kompletní správu v²ech vlastností jednotlivých poloºek, na místo toho jsem vybral jen ty (z mého pohledu) nejd·leºit¥j²í a ty zahrnul do implementace. Implementace v²ech dostupných vlastností podporovaných typ· by m¥la za následek nadbyte£n¥ velký objem p°ená²ených dat7 . Pokud by budoucí uºivatel pot°eboval n¥které vlastnosti poloºek, které nejsou v základu webovou sluºbou poskytovány, lze tyto vlastnosti s minimálním úsilím do webové sluºby doimplementovat8 . Nefunk£ní poºadavky na webovou sluºbu: • Sluºba bude fungovat v prost°edí IIS serveru • Sluºba bude kompatibilní s MSE 2010 • Sluºba bude implementována v MS .NET frameworku a bude napsána v jazyce C#
První poºadavek vyplývá ze zadání této práce, ostatní poºadavky jsou také v souladu s tímto zadáním.
3.3 Analýza webové sluºby P°i návrhu webové sluºby jsem se snaºil zachovat strukturu, kterou pouºívá EWS. D·vod· pro tuto snahu bylo n¥kolik. V prvé °ad¥ to bylo zjednodu²ení návrhu (není t°eba znovu vynalézat kolo, kdyº jiº bylo vynalezeno). Dal²ím d·leºitým d·sledkem je p°ehlednost návrhu, která je d·leºitá nejen pro vlastní vývoj, ale také pro p°ípadné pozd¥j²í úpravy. Poslední výhodou tohoto rozhodnutí je usnadn¥ní odstín¥ní MSE a EWS od klientské (webové) aplikace. Odstín¥ní MSE a EWS m·ºe být realizováno za pomoci návrhového vzoru (dále jen 'NV') Adapter[2] jehoº diagram je na obrázku 3.1. Tento NV °e²í problém nekompatibility dvou rozhraní objekt·, která nelze jednodu²e upravit (nap°íklad z d·vodu, ºe nemáme p°ístup ke zdrojovému kódu jednoho z t¥chto rozhraní). Adapter p°istupuje k °e²ení tohoto problému tak, ºe od¥d¥dí novou t°ídu (která tak nutn¥ implementuje jednu rozhraní jednoho z objekt·) a zárove¬ implementuje rozhraní druhého z objekt·. A£koli je tento p°ístup z hlediska návrhu velice £istý, jeho d·sledkem je zv¥t²ení po£tu t°íd a p°ínos je v pom¥ru k pracnosti implementace nízký. Proto jsem se rozhodl vytvo°it statickou metodou map() u jednotlivých t°íd, která zaji²´uje mapování zpracovávaných parametr· mezi typy z EWS a z webové sluºby. 7 Tento objem by byl zv¥t²en i kv·li faktu, ºe SOAP pouºívá k serializaci XML, které není vhodné pro p°ená²ení binárních dat 8 Vyºaduje rekompilaci a aktualizaci reference webové sluºby v cílovém projektu
10
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Obrázek 3.1: UML diagram návrhového vzoru Adapter Hierarchie t°íd je zobrazená na obrázku 3.2[11]. Tato hierarchie se velmi blíºí struktu°e EWS, je zde ale n¥kolik zm¥n. P°edn¥ byly vytvo°eny t°ídy ExEmailHeader a ExFolderHeader, které reprezentují 'hlavi£kové' informace pro poloºky typu EmailMessage, resp. Folder. Ve t°íd¥ ExEmailHeader navíc existuje vlastnost pro uchování za£átku9 t¥la emailové zprávy, coº je výhodné pro zobrazení náhledu zprávy p°i procházení adresá°e se zprávami a zárove¬ to sniºuje datovou zát¥º p°i hromadném na£ítání email· z adresá°e. Mén¥ významnou zm¥nou je de nice t°ídy ExItem jako abstraktní. Druhou hierarchií t°íd, kterou bylo nutné vytvo°it je hierarchie Response (Obrázek 3.2[11]). Tyto t°ídy zaji²´ují komunikaci s klientem webové sluºby. Základem je (op¥t) abstraktní t°ída Response, která zaji²´uje propagaci vyjímek, které byly vyhozeny p°i zpracování poºadavku klienta na stran¥ webové sluºby a/nebo EWS. T¥chto vyjímek m·ºe být vyhozena celá °ada, mezi ty nej£ast¥j²í pat°í odmítnutí p°ihlá²ení uºivatele a nedostupnost EWS na zadané adrese. Dal²í t°ídy v této hierarchii implementují komunikaci pro jednotlivý typy z hierarchie ExItem. Navíc byla p°idána t°ída StringResponse pro poºadavky, které nap°íklad vytvá°ejí poloºky na MSE serveru nebo ºádají jen o ID n¥které z poloºek.
3.4 Analýza webového rozhraní Pro vytvo°ení rozhraní byla zvolena technologie MS Silverlight, která umoº¬uje tvorbu aplikací spou²t¥ných v prost°edí prohlíºe£e. Tato aplikace je pouze prezenta£ní vrstvou celého systému. P°i návrhu webového rozhraní jsem vyuºil návrhový vzor proxy[5]. Ú£elem tohoto vzoru je 'zastoupit' objekt, se kterým se snaºíme manipulovat za pomoci jiného objektu, který 9
Prvních 80 znak· po odstran¥ní HTML formátování
3.4.
ANALÝZA WEBOVÉHO ROZHRANÍ
Obrázek 3.2: Diagram t°íd pro hierarchii ExItem
Obrázek 3.3: Diagram t°íd pro hierarchii Response
11
12
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Obrázek 3.4: Návrhový vzor proxy implementuje stejné rozhraní. Tento zástupný objekt se tak tvá°í jako prost°edník a zaji²´uje p°edávání poºadavk· od klienta na objekt, který zastupuje. Varianta, kterou jsem pouºil v tomto projektu se nazývá Remote Proxy jejím ú£elem je lokáln¥ zastoupit vzdálený (sí´ový) objekt. U tohoto webového rozhraní zastupuje Remote Proxy instanci webové sluºby - díky této proxy m·ºeme volat metody webové sluºby stejným zp·sobem, jako voláme metody jakéhokoli jiného lokáln¥ dostupného objektu. Velkou výhodou tohoto návrhového vzoru je transparentnost volání, díky kterému a polymor smu m·ºeme vyuºívat lokální i vzdálené objekty sou£asn¥, aniº bychom museli rozli²ovat s jakým objektem pracujeme. Je zde ale n¥kolik omezení, která musíme mít na pam¥ti. Nejd·leºit¥j²í v¥cí, se kterou se setkáme je propustnost volání p°es proxy. Volání webové sluºby je nutné omezit na nejnutn¥j²í minimum, protoºe její odezva je oproti volání (stejn¥ náro£ných metod10 ) na lokálních objektech o n¥kolik °ád· pomalej²í. Z tohoto d·vodu je nutné p°i implementaci pouºívat cache. Dal²í v¥cí, na kterou si musíme dát pozor je bezstavovost webové sluºby, která v tomto p°ípad¥ vyústila v nutnost posílat s kaºdým poºadavkem znovu p°ihla²ovací údaje uºivatele. Tento fakt má za následek nutnost uchovávat v pam¥ti heslo uºivatele po celou dobu b¥hu aplikace. Toto bezpe£nostní riziko je u desktopových aplikací relativn¥ snadno °e²itelné - nap°íklad v .NET Frameworku 4 m·ºeme vyuºít t°ídu SecureString (z namespace System.Security), která má podobné pouºití jako klasický String, ale zaji²´uje jeho ²ifrování v opera£ní pam¥ti11 . SecureString není dostupný pro Silverlight, jedinou moºností tak z·stává ²ifrovat tyto údaje za pomoci t°íd, které sami implementujeme12 . Poslední v¥cí, kterou Pokud tyto metody nejsou p°íli² výkonov¥ náro£né, kde by se mohl projevit vy²²í výpo£etní výkon serveru Pouºití t°ídy SecureString není 100% bezpe£né, ale poskytuje solidní zvý²ení bezpe£nosti dostupné s minimálním úsilím 12 Silverlight nabízí n¥které t°ídy z namespace System.Security, nap°íklad ²ifrovací algoritmus AES, hashovací funkci SHA-1 a knihovnu pro práci certi káty X.509 10
11
3.4.
ANALÝZA WEBOVÉHO ROZHRANÍ
13
je dobré zmínit je absence logiky u objekt·, které vrací webová sluºba v odpov¥di. To je zp·sobeno p°enosem objekt· p°es protokol SOAP. Po p°idání reference na webovou sluºbu do projektu získáme datové typy dostupné z webové sluºby, ale nezískáme jejich logiku. Tyto 'objekty' se budou chovat pouze jako kontejnery na data (v²echny vlastnosti mají public), tedy podobn¥ jako C++ typ struct (ale bez p°idaných metod!). Z tohoto d·vodu je nutné, aby byla konzistence objekt· kontrolována na stran¥ webové sluºby (zde objekty obsahují vlastní logiku).
14
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Kapitola 4
Realizace 4.1 P°ípravná fáze Pro úsp¥²nou realizaci jsem pot°eboval funk£ní MSE server, na kterém bych mohl testovat funk£nost webové sluºby. Spln¥ní této podmínky se ukázalo být náro£n¥j²í, neº jsem o£ekával. Nejd°íve jsem musel provést upgrade svého laptopu1 o 2GB RAM, aby bylo moºné virtualizovat 2. opera£ní systém. Tento upgrade si vyºádal instalaci opera£ního systému (dále jen 'OS') MS Windows 7 Professional ve verzi 64-bit (d°íve jsem pouºíval 32-bit verzi tohoto OS, protoºe 64-bit by mi nep°inesl ºádnou výhodu). Dal²ím krokem bylo nainstalování MS Windows Server 2008 R2 do virtuálního stroje. Pro virtualizací jsem zvolil Oracle VirtualBox2 . Po instalaci bylo nutné na serveru nastavit vytvo°it nový Domain Controller, DNS3 server, aktivovat a p°ipravit Active Directory na instalaci MSE 2010 serveru. Dále bylo nutné nakon gurovat sí´ová spojení mezi tímto virtuální serverem a OS Windows 7, který jeho b¥h umoº¬oval. Bohuºel mi chyb¥ly zku²enosti s instalací MSE a MS Windows Server, proto se mi instalace nepoda°ila napoprvé a bylo jí nutné n¥kolikrát opakovat. Úsp¥²nost instalace byla ov¥°ena funk£ností n¥kolika r·zných ú£t· v aplikaci MS Outlook 2010. Schéma testovacího prost°edí je znázorn¥no na Obrázku 4.1.
4.2 Poznámka V následující £ásti práce je popsáno pouºití EWS a vytvo°ené webové sluºby. Pro správnou funk£nost zde uvedeného kódu je nutné do projektu naimportovat knihovnu EWS, respektive namespace Microsoft.Exchange.WebServices a Microsoft.Exchange.WebServices.Data. Pro funk£nost p°íklad· z pouºitím webové sluºby je nutné tuto webovou sluºbu p°idat do projektu, udrºovat její referenci aktuální a pouºít namespace této sluºby. Kon gurace: Intel Core 2 Duo [email protected]; 2GB RAM; 160 GB, 5400 otá£ek HDD Dostupný pod GNU GPL v2 licencí 3 Domain Name System 1 2
15
16
KAPITOLA 4.
REALIZACE
Obrázek 4.1: Schéma testovacího prost°edí
4.3 Implementace datových hierarchií ExItem a Response V analýze byly tyto hierarchie t°íd navrºeny jako kontejnery pro p°enos dat protokolem SOAP, ale v pr·b¥hu implementace se objevila nutnost p°idat do t¥chto t°íd základní logiku. V prvé °ad¥ bylo nutné zajistit obousm¥rné mapování mezi objekty z hierarchie ExItem a jejími ekvivalenty z EWS. Tuto funkcionalitu jsem zprvu implementoval vn¥ t¥chto objekt· ve statické t°íd¥ Mapper, ale pozd¥ji se toto °e²ení ukázalo nepraktické, a proto je nyní obsaºena v jednotlivých t°ídách hierarchie. Druhou t°ídou s podobným osudem byla t°ída Properties, která zaji²´ovala správu dynamicky poskytovaných vlastností poloºek MSE. Metoda getProperies() je v t¥chto t°ídách ozna£ena jako statická, takºe byla zachována funkcionalita zamý²lená ve t°íd¥ Properties, jen byla refaktorována do jednotlivých t°íd. V návrhu hierarchie Response jsem nena²el zásadn¥j²í nedostatky, je implementována podle analýzy v p°edchozí kapitole.
4.4.
ZÁKLAD WEBOVÉ SLUBY
17
4.4 Základ webové sluºby Implementace webové sluºby je velice podobná implementaci b¥ºné knihovny funkcí s tím rozdílem, ºe musíme mít na pam¥ti bezstavovost (stateless) webové sluºby. Bezstavovost se projeví tím, ºe s kaºdým poºadavkem na MSE je nutné znovu odeslat uºivatelské jméno, heslo a adresu EWS, které jsou nutné k vytvo°ení instance t°ídy ExchangeService. ExchangeService spravuje p°ipojení k EWS4 . Pro usnadn¥ní p°edávání t¥chto povinných parametr· jsem pouºil t°ídu ExLogin, která uchovává vý²e zmín¥né poloºky a zkracuje hlavi£ky metod. Implementace je následující: private ExchangeService getExchangeService(ExLogin el) { ExchangeService es = new ExchangeService(ExchangeVersion.Exchange2010); es.Credentials = new WebCredentials(el.username, el.password); es.Url = new Uri(el.ewsAddress); return es; } [WebMethod] public StringResponse login(ExLogin el) { StringResponse response = new StringResponse(); ExchangeService es = getExchangeService(el); //dalsi logika, vytvareni odpovedi... return response; }
Bezstavovost webové sluºby lze obejít za pouºití HttpCache, do které budeme ukládat aktivní spojení. Toto °e²ení by bylo implementováno nap°íklad takto: [WebMethod] public StringResponse login(ExLogin el) { StringResponse response = new StringResponse(); ExchangeService es = getExchangeService(el); string token = Guid.NewGuid().ToString(); Cache cache = HttpRuntime.Cache; cache.Insert(token, es, null, Cache.NoAbsoluteExpiration, TimeSpan.FromMinutes(30)); //dalsi logika, vytvareni odpovedi... return response; }
4
v kontextu webové sluºby, která je spu²t¥na na stran¥ MSE serveru
18
KAPITOLA 4.
REALIZACE
[WebMethod] public StringResponse foo(string token) { Cache cache = HttpRuntime.Cache; object obj = cache[token]; ExchangeService es; if(obj != null) { es = (ExchangeService) obj; } //vlastni logika, vytvoreni odpovedi... }
Na tomto p°íkladu je dob°e patrné, ºe implementace této webové sluºby jako stavové (stateful) nep°inese ºádné zjednodu²ení ani výkonové optimalizace, spí²e naopak. Vytvá°ení instance t°ídy ExchangeService probíhá lokáln¥ a správnost zadaných údaj· není p°i volání konstruktoru ov¥°ována. Celkem je pot°eba p°enést 3 parametry typu string. Ve stateful implementaci je nutné na obou stranách udrºovat token spojení a dále musí server udrºovat kolekci aktivních spojení. Pro vyslání poºadavku je tedy nutné p°edat token, server jej musí vyhledat, provést p°etypování a následn¥ tuto instanci pouºít ke spojení s MSE. Navíc je zde nutné ov¥°ovat platnost jednotlivých token·, coº má za následek dal²í logiku a sníºení výkonu. Vý²e zmín¥né argumenty m¥ vedly k rozhodnutí neimplementovat vnit°ní stav webové sluºby.
4.5 Základ webového rozhraní Webové rozhraní je implementováno za pomoci MS Silverlight Navigation Frameworku, který byl p°edstaven v Silverlightu 3. Tento framework je zam¥°en na tvorbu webových aplikací a zjednodu²uje tvorbu webových aplikací. Zárove¬ p°iná²í upravený vzhled (podobá se spí²e dynamickým webovým stránkám neº desktopové aplikaci) a podporu template schématu. Template schéma se skládá z hlavní 'stránky'5 , která obsahuje menu a v²echny ostatní prvky, které budou ostatní stránky obshahovat. Navíc obsahuje tzv. Frame, do kterého bude vkládán obsah ostatních stránek. Tento princip pouºívají i ASP.NET, JSF6 , zde popisovaný Frame je obdobou ContentPlaceHolder z ASP.NET. Frame navíc obsahuje moºnost mapování jednotlivých stránek na speci cká URL7 - nap°íklad .../Views/About.xaml m·ºe být dostupné jako .../About. Tato vlastnost nám umoº¬uje efektnivn¥ skrýt vnit°ní strukturu aplikace p°ed uºivatelem. S tím souvisí i moºnost vyuºívat tla£ítka Zp¥t a Vp°ed webového prohlíºe£e pro navigaci v rámci aplikace. Posledním d·sledkem je moºnost generování URL na obsah nap°. .../Customers/3 (tato vlastnost m·ºe záviset na vnit°ním stavu aplikace). P°esn¥j²í ozna£ení by bylo formulá°, ale vzhledem k zam¥°ení na web jsem zvolil tento mén¥ p°esný, ale výstiºn¥j²í termín 6 Java Server Faces 7 Uniform Resource Locator 5
4.6.
REALIZACE PIHLAOVÁNÍ
19
4.6 Realizace p°ihla²ování První v¥cí, kterou bylo nutné vy°e²it bylo p°ihla²ování k MSE. Zde jsem narazil na problém, ºe EWS neobsahují moºnost p°ihlá²ení uºivatele. Autentizace uºivatele probíhá p°i kaºdém poºadavku. O správu p°ipojení k serveru zaji²´uje t°ída ExchangeService. Zde je d·leºité zmínit, ºe tato £ást kódu uºivatele nep°ihlásí ani nijak neov¥°uje platnost zadaných hodnot. Tento p°edp°ipravený objekt bude pouze pouºit pro vyhledávání poloºek na MSE a také bude injektován8 do n¥kterých nov¥ vytvo°ených objekt·. Pro ov¥°ení zadaných p°ihla²ovacích údaj· je nutné poºádat server o data. Pro toto ov¥°ení jsem zvolil poºadavek na ID ko°enového adresá°e uºivatele. Pokud toto volání usp¥je, bylo zadáno platné uºivatelské jméno, heslo a na zadané webové adrese je dostupný MSE. Klientovi je p°edáno ID ko°enového adresá°e. V opa£ném p°ípad¥ je vyhozena výjimka, kterou je nutné zpracovat a p°edat uºivateli. Z tohoto d·vodu jsem vytvo°il hierarchii Response popsanou v p°edchozí kapitole. ExLogin 'kontejner' pro snadn¥j²í a p°ehledn¥j²í p°edávání p°ihla²ovacích parametr· metod¥. Obsahuje uºivatelské jméno, heslo a adresu MSE. Struktura t¥la metody je následující: [WebMethod] public StringResponse foo(ExLogin el) { StringResponse response = new StringResponse(); try { ExchangeService es = getExchageService(el); // logika metody response.response = 'Foo succeded'; response.exceptionOccured = false;
} catch (Exception e) { response.exceptionOccured = true; response.exceptionMessage = e.Message; } }
return response;
V²echny t°ídy z hierarchie Response mají bezparametrický konstruktor, který je inicializuje do chybového stavu ( ag excptionOccured je true). Stav tohoto agu musí být nastavován jako poslední v dané metod¥ a zárove¬ musí být kontrolován na stran¥ klienta. Vý²e zmín¥ný kód tedy zaji²´uje spolehlivou propagaci výjimek ke klientovi. V uºivatelském rozhraní jsem p°ihla²ování vy°e²il pouºitím modálního9 okna, které se otev°e p°i spu²t¥ní aplikace a je automaticky zav°eno p°i úsp¥²ném p°ihlá²ení. Uºivatelské jméno Dependency Injection je také návrhový vzor[3] Modální okno blokuje ostatní okna aplikace ltrování smy£ky zpráv - zahazuje v²echny zprávy pro ostatní okna 8 9
20
KAPITOLA 4.
REALIZACE
a heslo je uchováno v otev°ené podob¥ pro pozd¥j²í pouºití v instanci t°ídy ExLogin10 . V následujících p°íkladech uvádím pouze obsah bloku try { }
zbytek metody je analogický s p°íkladem vý²e. Vstupní parametry budou okomentovány.
4.7 Vytvá°ení poloºek Pro vytvo°ení poloºky na MSE (nap°. odeslání emailové zprávy nebo vytvo°ení poloºky v kalendá°i) je nutné vytvo°it objekt daného typu. Konstruktory t¥chto typ· vyºadují jako parametr instanci ExchangeService. Dále musíme provést mapování dostupných vlastností pro poloºku a nakonec jí uloºit. Pro ukládání do speci ckých adresá°· m·ºeme pouºít statickou t°ídu WellKnownFolderName, která poskytuje ID základních adresá°· (Inbox, Calendar a dal²í) speci kovaného uºivatele. P°íklad implementace odeslání emailové zprávy: ExchangeService es = getExchageService(el); //ee je vstupním parametrem typu ExEmail EmailMessage message = ExEmail.map(es, ee); message.SendAndSaveCopy(); response.response = 'Sending email succeded'; response.exceptionOccured = false;
4.8 Získávání poloºek Pro stahování poloºek z MSE je pouºívána t°ída ItemView11 . Tato t°ída umoº¬uje stránkování výsledk·, speci kaci poskytovaných parametr· (zde je omezení na poloºky typu Item) a °azení. Výsledky vyhledávání jsou obsaºeny v generické t°íd¥ FindItemsResults<>. Tato t°ída také obsahuje celkový po£et poloºek v daném adresá°i a implementuje rozhraní IEnumerable. V p°íkladu jsou v 1. £ásti získány pouze ID jednotlivých poloºek, které jsou pozd¥ji staºeny pomocí statické metody Bind() t°ídy EmailMessage. Stahované vlastnosti jsou speci kovány pomocí t°ídy PropertySet. ExchangeService es = getExchageService(el); //vstupní parametry pageSize a pageOffset, int ItemView view = new ItemView(pageSize, pageOffset, OffsetBasePoint.Beginning); view.OrderBy.Add(ItemSchema.DateTimeReceived, SortDirection.Descending); view.PropertySet = new PropertySet(BasePropertySet.IdOnly); PropertySet ps = ExEmail.getProperties(); //vstupní parametr folderId, string 10 Toto je bezpe£nostní riziko nelze odstranit pouºitím t°ídy SecureString, která není pro Silverlight dostupná 11 A její potomci jako je CalendarView
4.9.
ÚPRAVA A MAZÁNÍ POLOEK
21
FindItemsResults- results = es.FindItems(folderId, view); response.folderSize = results.TotalCount; response.pageSize = pageSize; response.pageOffset = pageOffset; response.headers = new EmailHeader[pageSize]; int max = pageSize; if (results.TotalCount < max) { max = results.TotalCount; } for (int i = 0; i < max; i++) { response.headers[i] = ExEmail.map(EmailMessage.Bind( es, results.Items.ElementAt(i).Id.UniqueId, ps)); } response.exceptionOccured = false; response.exceptionMessage = '';
4.9 Úprava a mazání poloºek Pro úpravu a mazání jednotlivých poloºek je nutné znát jejich ID. ID poloºky získáme spolu s dal²ími parametry p°i stahování poloºek dle popisu vý²e. Pro úpravu musíme nejd°íve za pomoci metody Bind() získat tento objekt (volání metody Bind() zaji²´uje metoda Appointment.map()), provést mapování nových dat a následn¥ tento objekt uloºit. ExchangeService es = getExchageService(el); Appointment appointment = Appointment.map(es, ea); appointment.Save(SendInvitationsMode.SendToNone); response.exceptionOccured = false; response.response = 'Appointment succesfuly updated';
Vlastní mazání probíhá tak, ºe pouºijeme statickou metodu Bind() nad objektem daného typu a zavoláme metodu Delete() tohoto objektu. Povinným parametrem metody Delete() je DeleteMode, který speci kuje typ smazání s ohledem na typ mazané poloºky (p°esunout do ko²e, smazat, ale nap°íklad pro sch·zky odesílá oznámení o zru²ení). Následující kód p°esune poloºku typu EmailMessage do ko²e. ExchangeService es = getExchageService(el); //emailId je vstupní prametr, string EmailMessage email = EmailMessage.Bind(es, emailId); email.Delete(DeleteMode.MoveToDeletedItems);
22
KAPITOLA 4.
REALIZACE
response.exceptionOccured = false; response.exceptionMessage = ''; response.response = 'Email succesfuly deleted';
4.10 Roz²i°itelnost webové sluºby Roz²i°itelnost webové sluºby je jedním z cíl· této práce. Pro budoucí roz²í°ení je tato webová dob°e p°ipravena. Roz²i°itelnost t°íd z hierarchie ExItem je velice snadná. Pro p°idání nové vlastnosti poloºky musíme nejd°íve deklarovat prom¥nou pro tuto vlastnost v odpovídající t°íd¥ hierarchie ExItem, dále p°idat tuto vlastnost do PropertySet této t°ídy a zajistit pat°i£né mapování. Tato zm¥na se bez nutnosti zásahu programátora projeví i v pat°i£né t°íd¥ hierarchie Response. To je na stran¥ webové sluºby v²e. Po rekompilaci kódu a obnovení reference v klientské aplikaci m·ºeme za£ít tuto novou vlastnost vyuºívat.
4.11 Realizace klientské aplikace Abychom mohli vyuºít webovou sluºbu, jejíº implementace je zmín¥na vý²e, musíme tuto sluºbu p°idat mezi reference projektu. Dále musíme do kaºdé t°ídy, která bude tuto sluºbu vyuºívat p°idat namespace speci kovaný p°i p°idávání této sluºby do referencí projektu. Nyní m·ºeme vytvo°it proxy objekt, který nám poskytuje metody webové sluºby. Zde je nutné zmínit, ºe ve²kerá volání webových sluºeb jsou v Silverlightu asynchronní12 . Volání metody tedy vypadá takto: private void ButtonOK_Click(object sender, RoutedEventArgs e) { WebServiceSoapClient proxy = new WebServiceSoapClient(); proxy.fooCompleted += new EventHandler (proxy_fooCompleted); proxy.getfooAsync(); } private void proxy_fooCompleted(object sender, fooCompletedEventArgs e) { }
Pokud tedy voláme n¥jakou metodu webové sluºby (v p°íkladu se jedná o metodu foo()), musíme nejd°íve p°idat Event Handler na její dokon£ení a následn¥ jí zavolat. Po p°ijetí a zpracování odpov¥di je zavolán Event Handler, který má k dipozici návratovou hodnotu volání asynchronní funkce. Programová £ást webového rozhraní tedy za pomoci vytvá°ení a zachycování Událostí (Event) zobrazuje obsah poskytovaný webovou sluºbou. 12
Ale probíhají v rámci hlavního vlákna aplikace
4.12.
KOMPONENTY UIVATELSKÉHO ROZHRANÍ
23
4.12 Komponenty uºivatelského rozhraní D·leºitou £ástí této aplikace je p°epracovaná práce s kalendá°em a práv¥ s komponentou na vizualizaci dat z kalendá°e jsem m¥l nejvíce potíºí. V základní stavu Silverlight poskytuje jedinou komponentu na zobrazení kalendá°e - velice jednoduchý Calendar, který umí krom¥ zobrazení m¥síc· vrátit zvolený den. Vyhledávání komponent, které by m¥ly poºadovanou funk£nost a byly dostupné po GNU/GPL licencí je velice málo13 . P°esto se mi poda°ilo nalézt dv¥ komponenty, které jsou voln¥ dostupné a nabízejí pohodlnou práci s kalendá°em. První z t¥chto komponent je Calendar Control[1]. Tento projekt nabízí velmi p¥kné komponenty, ale z d·vodu, který se mi nepoda°ilo zjistit, jsou nestabilní14 . Oproti nim jednodu²²í Silverlight Scheduler Control[14] je stabilní a funk£ní (v sou£asné dob¥ stále ve fázi vývoje). Ve webovém rozhraní je pouºita komponenta Silverlight Scheduler Control. Mírn¥ rozporupln¥ na mne p·sobí je²t¥ komponenta Pager, která je ur£ena na stránkování velkého objemu dat. Tato komponenta je velice snadno pouºitelná a dob°e plní sv·j ú£el, ale pro její správnou funk£nost je nutné, aby stránkovaná data byla dostupná lokáln¥. Pokud lokáln¥ dostupná nejsou, tak jí nelze pouºít15 . Z tohoto d·vodu není pro stránkování email· a kontakt· tato komponenta pouºita. Poslední v¥cí, kterou jsem se snaºil vy°e²it je cachování dat (nap°íklad p°i listování mezi emailovými zprávami). Tento problém bohuºel nemá uspokojivé °e²ení, protoºe nelze na stran¥ klienta efektivn¥ zjistit, zda jeho cache obsahuje aktuální data nebo ne. EWS poskytují moºnost push/pull a streamované noti kace, ale bezstavovost webové sluºby znemoº¬uje propagaci t¥chto noti kací sm¥rem ke klientovi.
Placených komponent, které tuto funkcionalitu nabízejí je opravdu mnoho, p°íkladem m·ºe být spole£nost Telerik 14 Ve vizuálním návrhá°i MS Visual Studia nefunguje jejich dynamické na£ítání 15 Moºné °e²ení lokální nedostupnosti je podvrºení stránkované kolekce a zachycování událostí 13
24
KAPITOLA 4.
REALIZACE
Kapitola 5
Testování a zhodnocení implementované funkcionality 5.1 Testování Testování probíhalo pr·b¥ºn¥ po celou dobu vývoje obou £ástí práce. Pro testování byla pouºita infrastruktura popsaná v kapitole 4.1. Testování probíhalo metodami Black Box Testing a White Box Testing. Ov¥°ení implementované funkcionality bylo provád¥no za pomoci referen£ní aplikace MS Outlook 2010. P°i testování bylo odhaleno mnoho neo£ekávaných chyb a zárove¬ byl kladen d·raz na informativní charakter chybových hlá²ení. Výsledkem tohoto snaºení jsou chybové hlá²ky, které mají v¥t²í vypovídající hodnotu neº 'Unexpected error', 'Unhandled exception occured' a dal²í jim podobné, které jsou bohuºel stále velmi roz²í°ené.
5.2 Zhodnocení implementované funkcionality Funkcionalita obsaºená ve webové sluºb¥ poskytuje dobrý základ, na kterém je moºné postavit uºivatelsky p°ív¥tivou aplikaci nebo jej vyuºít pro integraci do nap°íklad vnitropodnikového informa£ního systému. Zárove¬ je dob°e p°ipravenou platformou pro dal²í roz²í°ení o nové funkce. Budoucí uºivatel, který ji bude chtít vyuºít v rámci svého projektu získá solidní základ, který m·ºe vyuºít 'tak jak je' nebo z n¥ho m·ºe vyjít a upravit jeho funkcionalitu do poºadovaného stavu.
25
26KAPITOLA 5.
TESTOVÁNÍ A ZHODNOCENÍ IMPLEMENTOVANÉ FUNKCIONALITY
Kapitola 6
Záv¥r 6.1 Napln¥ní cíl· Hlavním cílem této práce bylo vytvo°ení webové sluºby pro správu poloºek na MSE serveru. Pro jeho napln¥ní byla implementována webová sluºba, která poskytuje poºadovanou funkcionalitu, a proto se domnívám, ºe byl tento cíl napln¥n. Druhým cílem byla implementace odleh£eného webového rozhraní s p°epracovanou správou kalendá°· a jejich vylep²enou podporou. Tento cíl byl napln¥n pouze z £ásti, protoºe se nepoda°ilo implementovat rozhraní pro správu kalendá°· zp·sobem, který bych ozna£il za inovativní nebo p°ínosn¥j²í neº jaká nabízejí stávající aplikace. Zpo£átku mírn¥ opomíjené webové rozhraní se v kone£ném d·sledku ukázalo jako velmi pracné na implementaci, p°edev²ím z d·vodu nedostupnosti vhodných komponent pro vizualizaci dat a také jiným p°ístupem k prezentaci jako takové. V záv¥ru tvorby webového rozhraní mi velmi pomohla volba Navigation Frameworku, který umoº¬uje tvorbu klientských aplikací, které jsou vzhledov¥ velmi blízké b¥ºným webovým aplikacím.
6.2 Moºnosti dal²ího vývoje Sm¥r dal²ího vývoje webové sluºby je celkem jasný - roz²í°it paletu poskytovaných funkcí. S tím souvisí i nutnost pozm¥nit doménový model. Zajímavým sm¥rem by mohlo být implementování noti kací, pro které je nutná alespo¬ £áste£ná podpora stav·. Dal²ím zajímavým roz²í°ením by byla podpora p°íloh, coº je funkce, bez které se jen malé procento uºivatel· obejde. Posledním nemén¥ zajímavým roz²í°ením je internacionalizace celého projektu. Tato moºnost by byla velmi vítaná zejména v p°ípad¥, ºe by umoº¬ovala snadné p°idávání jazykových balí£k· bez nutnosti rekompilace zdrojového kódu. Pro dal²í vývoj webového rozhraní tohoto projektu je v sou£asné dob¥ asi nejzásadn¥j²í nalezení (nebo vytvo°ení) nové a lep²í komponenty pro vizualizaci poloºek kalendá°e. P°i vytvá°ení této komponenty by bylo jist¥ dobré zváºit implementaci funkce drag&drop, která by posunula komfort práce o velký kus vp°ed. Dal²í funkcí, kterou by uºivatelé ocenili je lep²í integrace pravého tla£ítka my²i do celého projektu. V sou£asnosti podporuje práci s pravým tla£ítkem pouze komponenta kalendá°e, coº je ²koda. Posledním vylep²ením, které bych rád 27
28
KAPITOLA 6.
ZÁV
R
zmínil je zm¥na implementace p°ihla²ování a správy hesel, protoºe sou£asná varianta není p°íli² bezpe£ná (spí²e je velmi nebezpe£ná).
Literatura [1] dixxieonmymind. Silverlight Control Library [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [2] Kolektiv prispevatelu Wikipedie. Adapter pattern [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [3] Kolektiv prispevatelu Wikipedie. Dependency injection [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [4] Kolektiv prispevatelu Wikipedie. Comparison of e-mail clients [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [5] Kolektiv prispevatelu Wikipedie. Proxy pattern [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [6] Kolektiv prispevatelu Wikipedie. List of mail servers [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [7] MACDONALD, M. Pro Silverlight 3 in C#. 1. Spring Street, New York, USA : Apress, 1st edition, 2009. [8] MACDONALD, M. Beginning ASP.NET 3.5 in C# 2008. 1. Spring Street, New York, USA : Apress, 2nd edition, 2007. [9] Microsoft Corporation. Exchange Server Developer Center [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [10] Microsoft Corporation. Microsoft Exchange Web Services Managed API 1.1 [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [11] Microsoft Corporation. Client application with the Client Acces server [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [12] Microsoft Corporation. Microsoft Developer Network [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . 29
30
LITERATURA
[13] Microsoft Corporation. Microsoft Exchange Server and Exchange Online [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [14] rgriesser. Silverlight Scheduler Control [online]. 2011. [cit. 23. 5. 2011]. Dostupné z: . [15] TROELSEN, A. Pro C# 2008 and the .Net Platform 3.5. 1. Spring Street, New York, USA : Apress, 4th edition, 2007.
P°íloha A
Seznam pouºitých zkratek MS
Microsoft Corporation
MSE
Microsoft Exchange
EWS
knihovna Microsoft Exchange Web Services
MS IIS
Mictosoft Internet Inforamation Services
Application Programming Interface
API RPC
Remote Procedure Call
MAPI
Messaging API
WebDAV
Web-based Distributed Authoring and Versioning
SOAP
Simple Object Access Protocol
MSDN
Microsoft Developer Network
Post O ce Protocol
POP
IMAP
Internet Message Access Protocol
SMTP
Simple Mail Transfer Protocol
CRUD
Create, Retrieve, Update, Delete
MS OWA MS CAL
Microsoft Outlook Web App Microsoft Client Access Licence
GNU/GPL
GNU General Public Licence
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
SSL
Secure Socket Layer 31
32
PÍLOHA A.
CLR
Common Language Runtime
ASP
Active Server Pages Asynchronous JavaScript and XML
AJAX OS
Operating System
NV
Návrhový vzor Hypertext Markup Language
HTML
Advanced Encryption Standard
AES
SHA-1
Secure Hash Algorithm
RAM
Random Access Memory
HDD
Hard Drive
DNS
Domain Name System
HTTP
Hypertext Transport Protocol
HTTPS JSF URL
Hypertext Transport Protocol Secure
Java Server Faces Uniform Resource Locator
SEZNAM POUITÝCH ZKRATEK
P°íloha B
Instala£ní a uºivatelská p°íru£ka Instalace programu do prost°edí MS IIS serveru probíhá následovn¥: • Nainstalujte MS IIS server verze 7.0 vy²²í, v£etn¥ podpory pro .NET Framework
a správu certi kát·.
• Spus´te IIS Manager a v hlavní nabídce serveru otev°ete nabídku Server Certi cates
a vytvo°te nový certi kát pro server (sta£í self-signed)
• P°es levé bo£ní menu vytvo°te novou Web Site (název nehraje roli, fyzická cesta do ko-
°enového adresá°e projektu, protokol HTTPS a certi kát z p°edchozího bodu)
• Otev°ete webový prohlíºe£ a na adrese
Druhou moºností spu²t¥ní je p°es p°iloºený projekt pro MS Visual Studio 2010. Pro instalaci jsou nutná administrátorská práva k hostitelskému po£íta£i.
Poºadavky na spu²t¥ní • MS IIS Server 7.0 a vy²²í • MS .NET Framework 3.5 a vy²²í • MS Silverlight 4.0 a vy²²í • Webový prohlíºe£
33
34
PÍLOHA B.
INSTALANÍ A UIVATELSKÁ PÍRUKA
P°íloha C
Obsah p°iloºeného CD P°iloºené CD obsahuje následující adresá°e a souboru: • soubor 'Readme.txt' v ko°enovém adresá°i - tento soubor obsahuje popis obsahu CD
a instala£ní p°íru£ku
• Adresá° 'Text bakalá°ské práce' - obsahuje PDF soubor 'bp-2011-dousepet.pdf' a ad-
resá° 'Tex' se zdrojem ve formátu Latex
• Adresá° 'Program', jehoº podadresá°e následují • Adresá° 'Instalace' se soubory pro p°ímou instalaci programu • Adresá° 'Zdrojový kód' s kompletním zdrojovým kódem programu
35
