Capitolul 8

Aplicaii ASP.NET

Capitolul 8

Aplicaii ASP.NET
n cadrul acestui capitol se vor trece n revist aspecte introductive despre infrastructura ASP.NET 2.0. Pentru construcia aplicaiile ASP.NET .NET Framework ofer foarte multe API-uri i instrumente de dezvoltare. Versiunea 2.0 de ASP.NET aduce i aceasta multe schimbri, capitolul de fa prezint doar cele mai importante noiuni ale acestei tehnologii Web. Aceste noiuni vor fi structurate n dou pri. Prima este introductiv i va cuprinde: modelul aplicaiilor ASP.NET, nouti n ASP.NET 2.0, serverul Web IIS, instalarea i configurarea aplicaiilor Web, structura unei aplicaii ASP.NET, Web Forms i controale Web, obiecte tipice ASP.NET. A doua parte este dedicat serviciilor Web: standarde n serviciile Web, expunerea unui serviciu Web, consumarea unui serviciu Web, proxy-ul unui serviciu Web, tranzacii n serviciile Web i utilizarea tipurilor definite de utilizator ntr-un serviciu Web. 8.1 Introducere n ASP.NET ASP.NET ofer un model de programare i o infrastructur prin cu ajutorul crora se pot dezvolta att aplicaii Web ct i servicii Web XML. Principalele caracteristici ale tehnologiei ASP.NET sunt urmtoarele: Aplicaiile ASP.NET sunt compilate. Unul din dezavantajele ASP1-ul clasic l constituia faptul c pagina Web coninea scripturi, deci un cod ce trebuia interpretat i apoi executat. ncepnd cu ASP.NET codul este compilat i apoi executat. Aplicaiile ASP.NET sunt compilate n dou faze: prima faz n care codul C# sau VB.NET (i altele) este compilat ntr-un assembly ce conine cod intermediar IL (aceast compilare poate avea loc n momentul primei cereri dac sursele nu sunt deja compilate) i a doua realizat de JIT chiar naintea execuiei propriu-zise a paginii i const n transformarea codului IL n cod nativ optimizat pentru sistemul pe care se afl serverul Web. O aplicaie Web nu este compilat de fiecare dat cnd o
1

ASP este acronimul pentru Active Server Pages. ASP.NET reprezint noua platform de programare a aplicatiilor Web ce folosete .NET Framework.

129

Sisteme Distribuite

pagin sau un serviciu Web este cerut, n schimb se folosete o metod de pstrare (cache) a codului deja compilat (JIT). Codul IL este recompilat de fiecare dat cnd sursele sunt modificate. ASP.NET este multi-limbaj. Se poate alege orice limbaj CLI pentru a dezvolta o aplicaie Web. Aceasta deoarece rezultatul compilrii va fi cod IL adic un cod scris pentru .NET i poate rula n interiorul unui mediului protejat oferit de CLR. O aplicaie ASP.NET folosete mediul de execuie oferit ce CLR. Acest lucru implic: Managementul automat al memoriei; Type Safety; Multithreading: o aplicaie Web poate utiliza la un moment dat mai multe fire de execuie pentru a: executa operaii asincrone (citirea unui fiier, apelul unui serviciu Web) sau pentru a executa o operaie n mod continuu pe durata de via a aplicaiei Web (de exemplu un fir cu prioritate sczut care la intervale regulate trebuie s salveze ntr-o baz de date nite informaii ); ASP.NET este orientat obiect. Cel mai bun exemplu este acela al controalelor server-side: controalele ce pot fi create i modificate programatic astfel nct s rspund ntr-un anumit fel la evenimente sau s aib un anumit aspect. Aplicaiile ASP.NET sunt uor de instalat i configurat. De cele mai multe ori instalarea unei aplicaii ASP.NET nseamn copierea fiierelor aplicaiei ntr-o cale de pe disc, cale configurat n IIS ca director virtual. Configurarea este la fel de simpl: fiecare aplicaie conine un fiier n format XML, web.config, n care sunt inute setrile. Poate fi modificat n timpul rulri iar aplicarea lor se face automat [Mac05]. 8.2 Nouti n ASP.NET 2.0 Noutile aduse de ASP.NET 2.0 sunt din urmtoarele categorii: Administrarea i dezvoltarea aplicaiilor Web; Controale server side; Legarea datelor n controale Web; Securitate. Pentru administrarea aplicaiilor Web .NET Framework include o consol de management ce are o interfa Web ce poate fi accesat de oriunde printr-un browser. n cadrul directorului rdcin al aplicaiei Web, ASP.NET 2.0 recunoate unele nume de directoare. Aceste directoare au anumite roluri i 130

Capitolul 8

Aplicaii ASP.NET

se ateapt pstrarea unor anumite tipuri de fiiere. De exemplu directorul cu numele App_Data este destinat fiierelor de date XML sau mdf i pentru pstrarea bazei de date ce conine informaiile despre utilizatorii site-ului i roluri. ncepnd cu ASP.NET 2.0 site-urile Web pot fi precompilate nainte de a fi instalate pe serverul de producie. Avantajele precompilrii sunt: se mbuntete timpul de rspuns pentru prima cerere a paginii deoarece aceasta nu mai este compilat dinamic; posibilitatea de a instala numai codul executabil fr codul surs. Tot cu ASP.NET 2.0, se pot crea uor interfee grafice consistente n paginile Web folosind pagini model (engl. master pages). Paginile master reprezint tema general aleas pentru un grup de pagini Web. Acest lucru este util ntruct paginile nu mai sunt construite de la zero ci avnd un model iar fiecare pagin reprezint o particularizare a acesteia. ASP.NET aduce o nou modalitate de configurare dinamic a paginii Web chiar de ctre client, prin folosirea controalelor Web Parts. Aceste controale sunt destinate site-urilor de tip portal care doresc o interfa interactiv cu utilizatorul oferind suport pentru diferite aciuni obinuite n cadrul aplicaiilor client: drag-and-drop, vizualizri configurabile, interaciuni ntre componentele paginii i altele. ASP.NET 2.0 introduce noi controale server cum ar fi: TreeView, SiteMapPath (un control utilizat la navigarea prin site-ul Web), FileUpload, ImageMap i altele. Codul markup generat pentru un control este compatibil cu XHTML 1.1 i este adaptabil n funcie de tipul i posibilitile clientului Web. Controalele pot fi legate la o surs de date. Cu noul model de legare a unui data source se poate defini modul n care pagina Web interacioneaz cu aceast, n mod declarativ. Aceast operaiune e mult mai uoar dect scrierea unui cod programatic logic (engl. cod behinde1) care s fac efectiv legtura ntre sursa de date i controlul Web. Dei autentificarea din ASP.NET 1.x, bazat pe cockie-uri, este nc soluia cea mai la ndemna pentru securizarea accesului pe un site Web, codul ce realizeaz autentificarea i autorizarea trebuia rescris pentru fiecare site n parte. n ASP.NET 2.0 a fost introdus suport pentru salvarea informaiilor utilizatorilor. 8.3 Internet Information Services (IIS) Internet Information Services reprezint un set de servicii Windows responsabile cu procesarea cererilor venite din reea pe un anumit port. n acest sens exist un serviciu Windows numit World Wide Web Publishing
1

Codul logic al aplicaiei ASP diferit de cel de prezentare

131

Sisteme Distribuite

Service ce ascult, de obicei pe portul 80 (HTTP) sau 443 (HTTPS), cereri pentru o anumit resurs la un site Web instalat. Acest serviciu Windows este administrat de un instrument numit IIS Manager.
Obs: - Pentru a deschide consola de management IIS trebuie lansat n execuie un program numit inetmgr.exe. Acesta poate fi gsit n directorul de instalare a IIS. Cea mai simpl cale de a deschide consola este prin utilitarul Run din Windows. - Visual Studio 2005 are integrat un server Web, Web Developer Web Sever, ce se poate executa independent de IIS. Visual Studio poate fi configurat s foloseasc acest server n loc de IIS.

n cadrul IIS, site-urile Web sunt grupate n directoare virtuale cu legturi ctre directoare existente pe disc sau configurate logic de Windows dar cu locaia pe alt main, n care se afl fizic aplicaiile Web. Resursele unei aplicaii Web sunt accesate de client prin intermediul unui browser cruia i precizm un URL. Aceast adres conine mai multe informaii ce vor indica: tipul protocolului, portul asociat aplicaiei n cadrul serverului (de regul 80), locaia virtual a resursei i cel mai important numele resursei sau al fiierului. S analizm URL-ul urmtor:
http://localhost:8080/AppWeb/index.aspx

n primul rnd se poate observa c protocolul folosit este http. Prin acest URL se face o cerere ctre un server, cu aliasul localhost, pe portul 8080, spre resursa index.aspx aflat n directorul virtual AppWeb. Extensia .aspx este foarte important ntruct procesarea depinde de tipul ei. Fiecare extensie de fiier are asociat n cadrul IIS o extensiune ISAPI1. Aceast extensie este reprezentat fizic de o bibliotec dinamic (un fiier DLL).
Obs: ntruct fiecare versiune de ASP.NET vine cu propriul ISAPI, IIS trebuie configurat astfel nct s tie pentru fiecare aplicaie n parte crei interfee s trimit cererea. n acest sens fiecare versiune de ASP.NET vine cu un utilitar de configurare aspnet_regiis.exe. Utilizrile cele mai frecvente sunt: 1. afiarea versiunilor de asp.net instalate: aspnet_regiis.exe lv 2. configurarea versiunii de ASP.NET pentru o aplicaie: aspnet_regiis.exe s W3SVC/1/ROOT/AppWeb 3. configurare versiunii de ASP.NET pentru toate aplicaiile: aspnet_regiis.exe i

Internet Service Application Program Interface

132

Capitolul 8

Aplicaii ASP.NET

De exemplu extensia pentru fiierele din ASP-ul clasic (*.asp) este asp.dll iar pentru fiierele ASP.NET (*.aspx i *.asmx ) este aspnet_isapi.dll. Dup ce se determin extensia asociat resursei Web, serverul IIS pred controlul procesrii API-ului din aceast bibliotec (sau ISAPI). Astfel resursele .aspx sau .asmx sunt date spre procesare mediului ASP.NET. Dac pe aceeai main exist dou versiuni de .NET atunci consola de administrare IIS va ofer posibilitate alegerii versiunii. Trebuie menionat c nainte de a trimite mai departe cererea, IIS face cteva preprocesri cum ar fi verificarea drepturilor de acces pentru resursa respectiv sau autentificarea utilizatorilor. Din acest motiv resursele aplicaiei trebuie configurate n cadrul IIS cu acces anonim i public. Dac exist fiiere ce nu trebuie accesate public acestea vor fi configurate separat. n cazul n care resursele sunt pagini atunci restricionarea accesului se face programatic din codul behind. O dat cererea ajuns la extensiunea ISAPI din ASP.NET procesarea efectiv a cererii este realizat de mediul .NET. Mai precis cererea este trimis unui proces separat ce reprezint mediul n care ruleaz ASP.NET (sau .NET runtime host)1. Acest proces difer n funcie de versiunea de IIS folosita. Pentru IIS 5.x acest proces se numete aspnet_wp.exe iar pentru IIS 6.0 W3WP.exe. n cadrul versiuni 5.x, aplicaiile ruleaz n contextul unui singur proces ns sunt separate prin domenii ale aplicaiei. Fiecare aplicaie ASP.NET ruleaz ntr-un domeniu separat astfel nct erorile dintr-o aplicaie s nu afecteze i celelalte aplicaii Web. Acest model ridic dou probleme: dac o aplicaie Web ce ruleaz direct pe serverul Web (de exemplu o aplicaie ASP clasic) i genereaz erori ce duc la nchiderea lui aplicaiile ASP.NET vor fi nchise i ele. Pentru aplicaiile ASP.NET nu este cazul ntruct sunt executate n domenii diferite i izolate. Pentru a rezolva aceast problem se poate configura, pentru fiecare aplicaie n parte, nivelul de protecie. Pentru nivelul cel mai mare aplicaie va rula pe un proces separat, mai precis n dllhost.exe. A doua problem este performana: trebuie schimbate contextele a dou procese (cel al serviciului Windows i cel al procesului lucrtor n care este executat CLR). Problema schimbrii contextului n varianta 6.0 este rezolvat prin includerea unui driver n kernel-ul Windows (HTTP.SYS), responsabil cu
1

Trebuie reamintit ca aplicaiile .NET ruleaz n cadrul unor procese Windows. Aceste procese sunt instane ale unor programe ce conin cod nativ (adic nu sunt managed) .

133

Sisteme Distribuite

recepionarea cererilor de la clieni i trimiterea lor direct ctre orice proces ce este nregistrat pentru anumite URL-uri. Aplicaiile Web sunt grupate n application pools iar pentru fiecare grup se execut n cadrul unei instane separate procesului lucrtor W3WP.exe. Acest model are dezavantajul c folosete mai multe instane ale CLR-ului ce consum memorie n plus. 8.4 Instalarea aplicaiilor Web (deployment) De obicei instalarea aplicaiilor ASP.NET nseamn copierea fiierelor ce compun aplicaia ntr-un director pentru care IIS menine o referin sub forma unui director virtual i modificarea fiierelor de configurare pentru asigurarea funcionalitii. Pentru majoritatea aplicaiilor cei doi pai sunt suficieni ns dac aplicaia folosete resurse externe sau trebuie s acceseze baze de date trebuie fcute cteva operaii suplimentare. De regul trebuie efectuai urmtorii pai [Mac05]: Copierea tuturor fiierelor necesare pentru compunerea aplicaiei Web. Dac se folosesc assembly-uri ce sunt accesate prin GAC acestea trebuie instalate prin utilitarul gacutil.exe. Dac aplicaia folosete baze de date serverul de baze trebuie configurat att cu baza de date i tabelele folosite ct i cu un cont de utilizator prin care procesul lucrtor s se poat conecta la server. n cazul SQL Server trebuie avut grij dac se folosete autentificarea integrat din Windows sau autentificarea pe server pentru accesul la baza de date. Soluia preferat este ultima ntruct serverul se poate afl pe alta main iar autentificarea prin Windows nu se mai poate realiza. Un alt aspect ce trebuie inut cont cnd se folosesc servere de baze de date aflate n reea este configurarea firewall-ului de pe acea main s accepte conexiuni la baza de date. Maparea directorului fizic de pe disc cu un director virtual creat n IIS. Setarea permisiunilor pentru contului utilizatorului procesului lucrtor ASP.NET. Utilizatorul Windows ce instaniaz procesul lucrtor trebuie s aib drepturi de acces la toate resursele pe care le folosete aplicaia Web. Setarea drepturilor se face din consola Computer Management. Setarea permisiunilor de acces la resursele aplicaiei (pagini, cod, fiiere de imagine). Trebuie reinut c n momentul n care expunem directorul aplicaiei pentru acces din afar expunem toate fiierele i directoarele din el. Este important s setm dreptul pentru fiecare fiier i director n parte. Cea mai des ntlnit greeal este aceea de 134

Capitolul 8

Aplicaii ASP.NET

a seta dreptul de listare pentru directorul aplicaiei, n acest fel toate fiierele sunt expuse pentru copiere, inclusiv cele surs i cele de interfaa (*.aspx). Trebuie avut ns grij ntruct anumite directoare i fiiere trebuie lsate pentru acces public (de exemplu fiierele CSS, imaginile ce compun o pagin Web, etc..); Modificarea fiierului web.config pentru mediul de lucru al aplicaiei. De regul acest lucru nseamn modificarea opiunilor de globalizare, autorizare, session state sau setrile de acces la baza de date ce se gsesc n fiierul configurare. Setarea parametrilor din fiierul de configurare machine.config. Unul din motive ar fi n cazul unui cluster de servere Web n care din motive echilibrare a ncrcrii aceeai aplicaie Web este instalat pe mai multe servere. Pentru a asigura consistena cererilor ce necesit autentificare serverele trebuie s aib aceeai cheie de criptare.

Obs: Crearea unui director implica urmtorii pai: 1. n consola de management IIS se deschide meniul contextual pe un nod din treeview-ul sau cel aflat sub meniul Action al ferestrei i se alege opiunea New i apoi Virtual Directory, aa cum se observ n figura 8.1. 2. se aleg opiunile pentru noul director virtual: cale fizic pe disc i drepturile de acces ( listarea directorului, citire, scriere );

Figura 8.1 Opiunea de creare a unui nou director virtual n cadrul consolei de management a IIS.

8.5 Anatomia unei aplicaii ASP.NET Aplicaiile ASP.NET sunt grupate n cadrul IIS n directoare virtuale. n acest fel directoarele fizice sunt expuse de ctre serverul Web pentru accesul din afar. n componena directorului aplicaiei pot intra mai multe fiiere i directoare. 135

Sisteme Distribuite

De regul o aplicaie Web este compus din urmtoarele ingrediente: Pagini Web: Reprezentate de fiierele cu extensia .aspx i definesc interfaa Web a aplicaiei; Servicii Web: Module ce ofer funcii utile aplicaiilor (nu numai Web) aflate pe alte calculatoare i pe diferite platforme. Aceste module sunt reprezentate de fiiere cu extensia .asmx; Fiiere de cod: De obicei o pagina Web este nsoit de un fiier de cod ce conine logica aplicaiei pentru pagina respectiv. n funcie de modul de separare a codului de interfa pot exista mai multe fiiere surs. De obicei numele fiierului surs este dat de cel al paginii Web prefixat de extensia tipului de cod surs (.cs sau .vb). De exemplu pentru pagina default.aspx avem fiierul surs (C#) default.aspx.cs. Fiierul surs poate fi schimbat prin setarea atributului CodeFile din directiva @Page, element aflat n antetul unei pagini ASP.NET; Un fiier de configurare numit web.config n care sunt pstrate opiunile pentru grupul de pagini Web coninute n directorul curent i subdirectoarele acestuia. Pot exista mai multe fiiere web.config n fiecare subdirector. La nivelul sistemului setrile din toate fiierele web.config sunt vzute unitar. O pagin Web poate accesa toate proprietile din fiierele web.config aflate n directorul curent i din toate directoarele ce compun calea ctre aceasta; Fiierul Global.asax: Conine funciile de tratare a evenimentelor globale ale aplicaiei (lansarea aplicaiei, cereri, etc.) Alte componente necesare compunerii aplicaiei. De obicei acestea sunt assembly-uri, imagini, CSS-uri, etc. n legtur cu fiierul Global.asax trebuie fcute cteva precizri. Dup cum am spus mai sus acest fiier permite scrierea codului de tratare pentru evenimentelor globale. Dei clienii site-ului nu acceseaz niciodat acest fiier, codul din acesta (sau din fiierul de code behind asociat) se execut ca rspuns la anumite evenimente. ncepnd cu ASP.NET 2.0 structura de directoare recunoscute automat s-a extins. Aceste directoare sunt prezentate n tabelul 8-1. Fiierul Global.asax nu conine cod HTML i nici ASP.NET n schimb conine metode cu nume predefinite ce sunt apelate n funcie de eveniment. Unele funcii sunt apelate la fiecare cerere a unei pagini altele doar o singur n funcie de context. Cele mai importante dintre acestea sunt prezentate n tabelele de mai jos (8-2 i 8-3). 136

Capitolul 8

Aplicaii ASP.NET

Tabel 8.1 Directoare din rdcina aplicaiei recunoscute automat de ASP.NET 2.0
Directoare Bin Descriere Conine toate assembly-urile precompilate (de obicei Dll) pe care aplicaia ASP.NET le folosete: clasele compilate ale paginilor Web i/sau serviciilor Web precum i assemblyurile refereniate. Conine codul surs pentru compilarea dinamic. De obicei sunt componente separate de logica aplicaiei: clase pentru logica de login sau acces la baza de date folosite n DAL (Data Access Layer). Assembly-urile rezultate n urma compilrii nu sunt depuse n Bin ci n directoare temporare utilizate pentru compilarea dinamic. n acest director sunt pstrate resursele globale ce sunt accesate de orice pagin din aplicaie. Aici pot fi pstrate i fiierele necesare pentru globalizare. Are aceeai semnificaie cu App_GlobalResources numai c aceste resurse sunt dedicate numai unei singure pagini. Acest director este folosit pentru pstrarea datelor fie c sunt fiiere de baze de date (de exemplu *.mdf) fie fiiere XML ce conin date. Tot aici se pstreaz i baza de date pentru ce furnizeaz informaii despre roluri i autentificare. Conine referine ctre servicii Web folosite de aplicaie: fiiere *.wsdl i *.disco. Acest director conine definiii pentru tipurile de browser-e pentru care este destinat aplicaia. Sunt fiiere XML ce descriu capabilitile pentru mai multe tipuri de browser-e. Dei ASP.NET realizeaz acest lucru global prin intermediul acestor definiii se pot obine comportamente diferite ale aplicaiei n funcie de browser. Aici sunt pstrate temele i skin-urile folosite n paginile aplicaiei.

App_Code

App_GlobalResources

App_LocalResources

App_Data
App_WebReferences

App_Browsers

App_Themes

Tabel 8-2 Funcii din Global.asax apelate la fiecare cerere

Metode Application_BeginRequest() Application_AuthenticateRequest() Application_AuthorizeRequest() Descriere Metoda apelat la nceputul fiecrei cereri. Metoda apelat chiar naintea autentificrii. Metoda apelat dup ce utilizatorul a fost autentificat i urmeaz s se verifice dac are autorizare pentru a intra pe pagin. Este chemat chiar nainte de terminarea tratrii cererii iar obiectele create sunt eliberate din memorie.

Application_EndRequest()

137

Sisteme Distribuite

Tabel 8-3 Metode din Global.asax apelate n funcie context

Metode Application_Start() Descriere Metoda este apelat atunci cnd aplicaia este lansat. Metoda este util pentru a iniializa variabile folosite n ntreaga aplicaie. Aceast metod este apelat chiar nainte de terminarea aplicaiei sau dup ce fiierul de configurare a fost actualizat sau cnd IIS trebuie repornit. Este apelat cnd o excepie nu a fost tratat n aplicaie. Metoda este invocat de fiecare dat cnd o nou sesiune este creat. Metoda este apelat cnd o sesiune este nchis. O sesiune se poate nchide automat dup o perioad de timp (implicit 20 de minute) dac nu au mai fost cereri pentru ea.

Application_End() Application_Error() Session_Start() Session_End()

8.6 Configurarea aplicaiilor ASP.NET Configurarea n ASP.NET se realizeaz prin fiiere de configurare XML. Acestea sunt uor de citit i editat, sunt uor de accesat i nu sunt niciodat protejate la scriere. Aceasta ultim proprietate uureaz procesul de configurare ntruct schimbrile n fiierul de configurare sunt aplicate automat de IIS i nu manual prin intermediul unei comenzi de repornire a serverului. Primul fiier de configurare ce trebuie luat n considerare este cel care stabilete setrile pentru ntregul sistemul: machine.config. Aici se pot seta opiunile pentru procesul lucrtor sau nregistrarea diferiilor furnizori implementai de utilizator sau definii deja n .NET. Acest fiier se gsete n directorul Config din directorul de instalare a versiunii de .NET Framework i de exemplu acesta poate fi:
c:\[WinDir]\Microsoft.NET\Framework\[Version]\Config

Pe lng acesta n acelai director se mai afl i un fiier web.config ce conine setri adiionale. Aici pot fi adugai handler-i de HTTP sau tipurile de module HTTP ce vor fi folosite, de procesul lucrtor pentru a procesa cererile http. n versiunea 1.x aceste setri se aflau n machine.config. Toate aplicaiile Web motenesc setrile din aceste dou fiiere. n plus setrile din aceste fiiere se pot modifica pentru fiecare aplicaie n parte sau se pot insera setri particulare prin crearea unui nou fiier web.config n acelai director unde se afl grupul de pagini crora le 138

Capitolul 8

Aplicaii ASP.NET

sunt destinate setrile. Trebuie menionat c nu orice setare din fiierele primare de configurare se poate modifica. Aplicaiile ASP.NET folosesc un sistem de configurare ierarhizat pe mai multe nivele ce permit utilizarea unor anumite setri pentru fiecare parte a aplicaiei. Pentru a folosi aceasta tehnic trebuie create subdirectoare n cadrul directorului rdcin al aplicaiei. Fiecare subdirector motenete setrile directorului printe. De exemplu dac structura directorului virtual AppWeb ar avea un subdirector SubAppWeb fiecare cu un fiier web.config pentru paginile din AppWeb se vor aplica mai nti setrile din machine.config i web.config (din directorul Config) i apoi cele din fiierul web.config local. Pentru paginile aflate n SubAppWeb se mai aplic toate setrile de pn acum la care se aduga cele din fiierul web.config aflat n directorul local. Coninutul unui fiier de configurare ASP.NET este cuprins n interiorul tag-ului <configuration>, ce reprezint nodul root al documentului XML. Cele mai folosite elemente (sau seciuni) din fiierul de configurare al aplicaiei .NET sunt prezente n listingul urmtor (listing 8-1):
Listing 8-1 Un fiier de configurare web.config <?xml version="1.0"?> <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> <appSettings> <add key="MessageOfTheDay" value="My quote"/> </appSettings> <connectionStrings> <add name="PubsConnString" connectionString= "Data Source=localhost;Initial Catalog=pubs;Integrated Security=SSPI"/> </connectionStrings> <system.Web> <pages> <namespaces> <clear /> <add namespace="System" /> <add namespace="System.Collections" /> <add namespace="System.Configuration" /> <add namespace="System.Text" />

139

Sisteme Distribuite

<add namespace="System.Web" /> <add namespace="System.Web.UI" /> </namespaces> </pages> <authentication mode="Windows"/> </system.Web> </configuration>

Trebuie fcut observaia c pentru aplicaiile ASP.NET elementul sub care pot fi introduce opiuni este <system.Web>. n exemplul anterior elementul <pages> cuprinde un element <namespaces> n care sunt listate toate namespace-urile folosite n timpul fazei de precompilare. Tot n <system.Web> putem alege modul de realizare a autentificrii utilizatorilor care cer o pagin. n exemplu anterior autentificarea se face pe baza celei din Windows. Alte elemente des utilizate din <system.Web> sunt prezentate n tabelul urmtor (tabel 8-4):
Tabel 8-4 - Elemente cel mai des utilizate din <system.Web> ntr-un fiier de configurare
Membri <compilation> <customErrors> <sessionState> <webServices> Descriere Element ce conine alt element <assemblies> n care se pot lista assembly-urile folosite n aplicaie Element ce precizeaz un URL de redirectare atunci cnd o eroare apare n cadrul aplicaiei n cadrul acestui element se poate configura locaia unde se pstreaz starea sesiunii (n memorie, pe un server SQL) sau modul n care sunt utilizate cookie-urile n aplicaie. Cu acest element se pot configura serviciile Web pe care aplicaie Web le utilizeaz: protocolul, portul, etc.

Sistemul de configurare al aplicaiilor .NET conine i alte dou elemente des utilizate n aplicaiile ASP.NET: <appSettings> i <connectionStrings>. Ultimul poate fi utilizat ncepnd cu versiunea 2.0 a .NET i prin intermediul sau se pot defini mai multe conexiuni la o baz de date. Setrile proprii aplicaiei se pot aduga n elementul <appSettings> sub forma unor perechi cheie-valoare. Valorile i cheile pot fi doar de tip ir caractere, ntruct valorile atributelor unui element XML pot fi valori de tip ir de caractere. Accesarea i modificarea setrilor din interiorul aplicaiei se 140

Capitolul 8

Aplicaii ASP.NET

face prin folosirea claselor WebConfigurationManager i Configuration1. Clasa WebConfigurationManager conine urmtorii membri utili pentru accesarea setrilor (tabel 8-5):
Tabel 8-5 Cei mai importani membri ai clasei WebConfigurationManager
Membri AppSettings ConnectionStrings OpenWebConfiguration() Descriere Proprietate ce acceseaz elementele din <appSettings>. Accesarea se face pe baza numelui precizat de atributul key. Proprietate prin care se pot obine string-urile de conexiune din <connectionStrings>. Metoda returneaz un obiect de tip Configuration prin intermediul caruia se pot edita setrile aplicaiei

Pentru exemplu de fiier de configurare de mai sus (listing 8-1) avem urmtoarele utilizri ale membrilor clasei WebConfigurationManager prezentai, n tabelul 8-5, ilustrate n listingul 8-2.
Listing 8-2 Utilizarea membrilor WebConfigurationManager pentru fiierul de configurare prezentat la 8-1. string MOTD=WebConfigurationManager.AppSettings["MessageOfTheDay"]; string connStr=WebConfigurationManager.ConnectionStrings["PubsConnString"]; Configuration config = WebConfigurationManager.OpenWebConfiguration(Request.ApplicationPath); config.AppSettings.Settings["MessageOfTheDay"] = "New MOTD"; config.Save(); Obs: ncepnd cu ASP.NET 2.0 setrile pentru aplicaiile Web se pot edita prin intermediul Website Administration Tool (WAT). n esen reprezint o aplicaie ASP.NET ce permite prin intermediul unei interfee Web modificarea sau crearea unor setri n diferite seciuni ale fiierului de configurare. Pentru a deschide consola WAT, din Visual Studio 2005 se alege din meniu Website opiunea ASP.NET Configuration.

Referitor la codul anterior (listing 8-2), trebuie observat c metoda OpenWebConfiguration() primete ca parametru o cale virtual (mai precis calea virtual a directorului din care a fost cerut o resurs), unde se afl un fiier de configurare i returneaz un obiect de tip Configuration ce conine toate setrile motenite pn la nivelul acestui director virtual.

Clase noi introduse n .NET Framework 2.0 aflate n System.Configuration i System.Web.Configuration

141

Sisteme Distribuite

8.7 ASP.NET Web Forms Paginile Web din ASP.NET sunt denumite oficial Web Foms i permit cererea unei aplicaii Web n acelai mod n care este construit o aplicaie Windows folosind aceeai interfa bazat pe controale. Pentru nelegerea lor trebuie reinute urmtoarele aspecte: Aplicaiile ASP.NET sunt executate pe server iar ceea ce apare n browser-ul clientului reprezint rezultatul acestei execuii. Ceea ce se genereaz n urma execuiei unei pagini este cod HTML. ASP.NET genereaz cod HTML n funcie de posibilitile de afiare ale browser-ului. Pentru interaciunea cu utilizatorii ASP.NET folosete o tehnic numit postback prin intermediul creia sunt transmise napoi la server date despre aciunea efectuat de utilizator. O dat ce ASP.NET primete aceste date lanseaz evenimentul asignat acelei aciuni. Aplicaiile Web sunt aplicaii care nu pstreaz starea curent. nainte de a transmite codul HTML pentru afiare n browser, toate obiectele care au fost construite pentru realizarea acestui cod HTML sunt distruse. Pentru remedia acest lucru se folosesc tehnici precum view state sau query string i obiecte persistente pentru un anumit context: sesiune sau aplicaie. n continuare vor fi prezentate aspecte legate: modelul controlului din interfaa cu utilizatorul i procesarea paginilor ASP.NET . 8.8 Web Forms Controale ASP.NET Controalele ASP.NET sunt n esen clase din biblioteca .NET Framework reprezint elementele vizuale dintr-un Web Form i a cror funcionalitate de baz este de a genera cod HTML. Ierarhia de clase pentru controale server este ilustrat n figura 8.2.

Figura 8.2 - Ierarhia de clase a controalelor Web

142

Capitolul 8

Aplicaii ASP.NET

Clasa din care sunt derivate toate controalele server este Control i se afl n namespace-ul System.Web.UI. Nu trebuie confundat cu cea din care sunt derivate controalele pentru Windows Forms. Cei mai des folosii membri ai acestei clase sunt prezentai n tabelul urmtor (tabel 8-6). Controalele server HTML din cadrul System.Web.UI.HtmlControls constituie adaptoare (sau wrapper-e) peste controalele standard HTML. Acestea sunt declarate la fel ns se mai adug atributul runat=server pentru a se specifica faptul c sunt executate pe server. Orice control HTML poate fi transformat ntr-unul server dac se adaug acest atribut. Dac nu exist o coresponden direct n biblioteca de clase, ASP.NET va folosi clasa HtmlGenericControl. n total sunt 20 de tipuri de controale avnd clasa de baz HtmlControl. Ierarhia de clase este prezentat n figura 8.3.
Tabel 8-6 - Cei mai importani membri ai clasei Control
Membri ClientID Controls EnableViewState ID Page Parent Descriere Proprietate ce ntoarce identificatorul controlului adic un nume unic ales la instanierea paginii. Returneaz o colecie de controale coninute n acest control. Proprietate boolean prin care se activeaz sau dezactiveaz pstrarea strii acestui control n urma unui postback. Implicit este true. Returneaz sau seteaz identificatorul (de tip String) pentru acest control. Prin intermediul acestui nume controlul poate fi accesat n scripturile server side i n cod. Returneaz o referin la obiectul paginii printe. Returneaz o referin la controlul printe. Acesta poate fi un obiect de tip Control sau Page. Trebuie observat ca obiectul paginii este tot un control. Returneaz sau seteaz dac acest control este vizibil sau nu. n cazul n care proprietatea este setat pe false atunci nu se va genera tag-ul HTML corespunztor. Metoda ce realizeaz legarea controlului i a tuturor controalelor pe care le conine la sursa de date. Metoda care caut un control copil dup nume n controlul curent sau n toate controalele pe care le conine. Este returnat o referin la tipul Control ce apoi poate fi convertita la tipul corespunztor. Tipul este returnat de metoda GetType(). Metoda prin intermediul creia este generat codul HTML al acestui controlului. Nu este apelabil direct ntruct accesul este protected, n schimb ASP.NET cheam aceast metod cnd pagina este afiat.

Visible DataBind()

FindControl()

Render()

143

Sisteme Distribuite

Figura 8.3 - Clasele de controale generice HTML din namespace-ul

System.Web.UI.HtmlControls

Cea de-a dou categorie important de controale o reprezint cea a controalelor Web. Ierarhia de clase se poate observa n figura urmtoare (figura 8.4):

Figura 8.4 - Ierarhia de clase a controalelor Web din namespace-ul

System.Web.UI.WebControls

Aceste tipuri de controale au aceeai funcionalitate ca a controalelor HTML dar conin un set proprieti i metode mult mai uor de neles i folosit. De exemplu setrile de stil la cele de tip html se aplic prin precizarea unui CSS, pe cnd la cele web acest lucru se face programatic prin setarea unor proprieti. n plus tipurile de controale sunt destul de limitate ca numr i ca funcionaliti ntruct depind de standardul HTML. 144

Capitolul 8

Aplicaii ASP.NET

Controalele Web din ASP.NET ofer o mult mai multe tipuri controale i cu funcionaliti mai complexe. Clasele de baz pentru aceste controale sunt WebControl i BaseBoundControl pentru controale ce reprezint structuri de date complexe (liste, arbori). Alte diferene ntre cele dou tipuri de controale sunt: WebControl ofer un model mult mai abstract i mai consistent dect controalele server HTML; Controale Web pot genera mai multe tag-uri HTML plus acolo unde este cazul JavaScript; Declararea lor se face cu sintaxa <asp:tipcontrol> avnd grij s prefixm numele cu asp:. Acest prefix ajut la distingerea celor dou tipuri. Controale Web trebuie s se supun urmtoarelor reguli: Fiecare declaraie trebuie s aib un tag de nchidere sau un element gol /> la sfrit. Tag-urile ASP.NET urmeaz aceleai reguli ca XHTML; Toate controalele Web trebuie declarate cu atributul runat setat pe server chiar dac nu declaseaz un postback. Acest lucru nu este aplicabil n cazul celor html. n cadrul controalelor Web exist dou tipuri speciale ce controale: Rich sau avansate: Acestea au posibilitatea de a genera cantiti mari de cod HTML i JavaScript pentru a crea interfaa. De exemplu controlul de tip calendar sau TreeView; Controale de validare: Permit validarea datelor de intrare pentru un control. De exemplu se poate restriciona tipul i numrul caractere folosite ca date de intrare pentru un control de tip Textbox. Pe lng aceast clasificare controalele Web mai pot fi grupate n funcie de specializarea lor: Controale pentru reprezentarea structurilor de date. Aici sunt incluse controalele de tip grid i list, proiectate pentru a putea afia cantiti mari de informaie, permind paginarea, editarea sau sortarea elementelor. Un al aspect nou introdus n cadrul acestor date este folosirea modelelor ce permit crearea de controale adaptabile la tipul de vizualizare dorit; Controale de navigare: permit utilizatorului navigarea prin structura site-ului Web;

145

Sisteme Distribuite

Controale de login: aceste controale sporesc munca n realizarea de paginii de login ntruct interfaa lor este adaptabil i urmeaz modelul de autentificare din ASP.NET; Web Parts: Reprezint un set de controale utilizate n construcia portalelor i site-urilor Web configurabile de ctre utilizatori; Controale Mobile ASP.NET: Sunt controale asemntoare cu cele Web ns sunt adaptate pentru clieni mobili cum ar fi dispozitive precum PDA sau Smartphone sau orice telefon mobil ce poate afia pagini n standardele HTML i WML (Wireless Markup Language). Runtime-ul ASP.NET genereaz cod WML sau HTML n funcie de capabilitile clientului de HTTP aflat pe dispozitivul mobil.

8.9 Web Forms Procesarea paginilor ASP.NET Pentru nelegerea modelului de procesare a paginilor ASP.NET este vital cunoaterea fazelor procesrii i ordinea n care sunt executate i evenimentele care le ridic. n mare orice pagin ASP.NET parcurge 6 etape importante [Mac05]. 1. Crearea i iniializarea paginii (ASP.NET). n prima faz ASP.NET creeaz obiectul paginii, genereaz controalele definite cu tag-uri n fiierul aspx. n plus dac cererea este un postback, informaia de view state este deserializat i apoi pe baza ei sunt iniializate controalele. La acest pas este generat evenimentul Page.Init. Acesta este rar folosit ntruct unele controale ori nu au fost create ori nu au fost iniializate cu informaia din view state. n aceast etap operaiile de creare i iniializare sunt efectuate automat de CLR. 2. Iniializarea paginii din codul aplicaiei. n aceast faz obiectele pentru controale au fost deja create i iniializate fie cu valorile implicite fie cu informaia din view state. Evenimentul ce marcheaz aceast etap este Page.Load executat la fiecare cerere chiar dac este postback. Diferenierea ntre cele dou aciuni se face prin inspectarea proprietii statice Page.isPostBack. Acest moment este indicat pentru iniializarea controalelor cu date obinute prin operaii consumatoare de timp i trebuie iniializate o singur dat. De exemplu afiarea unei tabele ntr-un control GridView: la un eventual postback se verific proprietatea isPostBack i se trece peste preluarea tabelei din baza de date. n celelalte cazuri activarea view state-ului (proprietatea Control.EnableViewState) rezolv iniializarea obiectului ce reprezint controlul. 146

Capitolul 8

Aplicaii ASP.NET

3. Validarea. ASP.NET introduce controale noi de validare ce realizeaz verificarea automat a datelor introduse de utilizatori iar unde este cazul afieaz mesaje de eroare. Aceste controale intr n funciune dup ncrcarea paginii dar nainte de tratarea celorlalte evenimente. Dac o pagin a fost validat se poate determina prin proprietatea Page.IsValid. 4. Tratarea evenimentelor. nainte de acest punct, controalele sunt create i iniializate iar pagina este validat. n general evenimentele controalelor Web pot fi clasificate n dou categorii: declanate imediat (butoane, link-uri sau controale ce utilizeaz funcia JavaScript __doPostBack()) i cele declanate la o schimbare de stare (de exemplu selectarea unui element dintr-o list drop-down). n cazul unor controale Web, din .NET 2.0 evenimentele de schimbare de stare pot declana postback automat prin setarea pe true a proprietii AutoPostBack. n caz contrar evenimentul se va executa la urmtorul postback. 5. Legarea automat a datelor (engl. data binding). Pentru controalele ce folosesc surse de date exista dou momente n care se interogheaz sursa de date: unul chiar naintea evenimentului Page.PreRender i const n actualizarea sursei (inserri, tergeri i actualizare) i a doilea dup tratarea evenimentului n care datele sunt preluate din sursa de date i aduse controalelor la care sunt asignate. Acest model vine cu o limitare ntruct nici o funcie de tratare a unui eveniment nu poate accesa ultimele date luate din sursa de date; evenimentul Page.Unload este declanat dup ce codul HTML a fost generat. Evenimentul Page.PreRender semnific ultima aciune nainte de generarea codului HTML. 6. Distrugerea obiectelor. Aceast faz ncheie ciclul de via al unei pagini Web i const n distrugerea obiectelor componente ale paginii i este precedat de evenimentul Page.Unload. Orice resurs unmanaged trebuie dealocat la acest pas. n acest sens exist evenimentul Page.Dispose declanat cnd pagina este distrus de garbage collector.
Obs: Termenul de postback se refer la o aciune specific pentru o pagin Web interactiv ce const n trimiterea ei n forma n care se afl pe calculatorul utilizatorului napoi la server pentru procesare.

147

Sisteme Distribuite

8.10 Obiectele ASP.NET i gestionarea strilor obiectelor Fiecare pagin, la nivel de code behinde, este derivat din clasa Page din namespace-ul System.Web.UI. Clasa nou creat motenete pe lng o mare funcionalitate i cteva proprieti utile: Session, Application, Request ,Response, Server i User. Aceste proprieti corespund unor obiecte de sine stttoare din ASP clasic i de aceea n continuare ne vom referi la aceste obiecte prin numele proprietilor. Obiectul Request este o instan a clasei HttpRequest din namespace-ul System.Web. Acest obiect reprezint contextul cererii HTTP care a determinat ncrcarea paginii i conine informaii despre parametrii din URL i informaiile trimise de browser-ul clientului. Civa dintre cei mai des folosii membri ai acestui tip sunt prezentai n tabelul tabel 8-7.
Tabel 8-7 Membri obiectului Request
Proprietate ApplicationPath PhysicalPath Cookies QueryString Descriere ntoarce calea relativ ctre directorul virtual curent al aplicaiei. ntoarce calea fizic a directorului aplicaiei. ntoarce o colecie de coockie-uri trimise de acesta cerere. ntoarce o tabel hash avnd drept cheie numele parametrului din lista de parametri dai prin URL.

Obiectul Response este reprezentat de clasa HttpResponse aflat n namespace-ul System.Web. ntruct controalele Web pot genera cod HTML acest obiect nu este utilizat foarte rar pentru a genera programatic cod HTML. O utilizare frecvent este realizarea unei redirectri. Acest lucru se realizeaz prin metoda Redirect(). Un scenariu n care poate utilizat este atunci cnd un utilizator ncearc s intre pe o pagin i nu are destule drepturi, atunci va fi redirectat ctre o pagin ce conine un text de eroare sau un dialog de login. Alt scenariu des ntlnit implic folosirea query string pentru a transmite parametri paginii de redirectare. Exist un mic inconvenient ntruct redirectarea nu se face automat: se trimite un mesaj napoi la browser i l informeaz despre noua pagin. Obiectul Sever este reprezentat de clasa HttpServerUtility din cadrul aceluiai namespace ca i obiectele prezentate pn acum i conine funcii i proprieti ajuttoare. n cadrul acestei clase o funcie util este Tranfer() ce realizeaz o redirectare ctre o pagin din aplicaia curent. Dei nu poate 148

Capitolul 8

Aplicaii ASP.NET

face redirectare ctre alt pagin aflat pe alt server Web sau non-ASP.NET este mai rapid dect Request.Redirect() ntruct nu se mai transmite nici un mesaj browser-ului Web. La fel de util este i funcia MapPath(). Dac este folosit mpreun cu Request.ApplicationPath se obine o cale fizic absolut ca n exemplul urmtor:
string physicalPath = Server.MapPath(Request.ApplicationPath + "/info.txt"));

Obiectul User conine informaia despre utilizatorul care iniiaz cererea curent i permite testarea rolului. Clasa care implementeaz interfaa este System.Security.Principal.IPrincipal. Obiectul sesiune este o instan a clasei HttpSessionState din namespace-ul System.Web.SessionState. Este proiectat pentru a pstra orice date specifice pentru un singur utilizator ntre cereri. Obiectul sesiune ofer un dicionar de elemente ce reprezint datele utilizatorului pentru aceast sesiune. n spatele acestui obiect se afl o ntreag arhitectur ntruct meninerea informaiilor despre sesiune nu face parte din standardul HTTP. Principalele caracteristici ale acestui model de gestionare a strilor sunt: Permite pstrarea tuturor tipurilor serializabile. Cele neserializabile pot fi pstrate doar dac sesiunea este configurata in-process; Meninerea datelor se face n memoria serverului, folosind un proces separat sau memorate ntr-o baz de date; Timpul de via al sesiunii implicit este de 20 de minute de la ultima cerere ns poate fi modificat programatic; Obiectul poate fi accesat din toat aplicaia.
Obs: Configurarea sesiunii, aa cum precizm anterior, se poate face prin actualizarea elementului <sessionState> din fiierul de configurare web.config .

Pentru pstrarea evidenei sesiunilor deschide, ASP.NET folosete un identificator unic pe 120 de octei prin intermediul cruia poate diferenia sesiunile existente. Trebuie reinut c de fiecare dat cnd este deschis o nou sesiune este creat un nou identificator i trimis browser-ului client. n ASP.NET exist dou moduri de transmitere a acestei informaii: implicit, printr-un cookie, ce are implicit numele ASP.NET_SessionId sau n cazul n care clientul nu suporta cookie-uri prin inserarea n cadrul URL-lui ca n exemplul urmtor:
http://localhost/WebApp/((tmyvyy54esofk4g5cffbiqash)/index.aspx

149

Sisteme Distribuite

Pentru configurarea celor dou moduri exist atributele cookieless i cookieName din elementul <sessionState> al fiierului de configurare web.config. Acestea se folosesc dup cum urmeaz:
<sessionState cookieless="UseCookies" cookieName="ASP.NET_SessionId" />

Exist trei moduri de lucru pentru o sesiune: 1. InProc: obiectele ce compun starea sesiunii sunt pstrate n spaiul de memorie rezervat domeniului aplicaiei ASP.NET. Aceasta este opiunea implicit pentru modul de operare a sesiunii. Un aspect negativ ar fi acela c starea sesiunii fiind pstrat n memorie se poate pierde foarte uor dac domeniul aplicaiei sau serverul sunt repornite. Cu toate acestea ofer o performan mai ridicat dect celelalte moduri i se pot pstra obiecte chiar i neserializabile; 2. StateServer: innd cont c domeniul aplicaiei sau serverul Web se pot reiniializa pierzndu-se informaiile din starea sesiune, ASP.NET folosete un proces separat aspnet_state.exe (sub forma unui serviciu Windows). Acest mod este util nu numai pentru a preveni pierderea de informaii ci i pentru a sincroniza datele cnd aplicaia se execut ntr-un cluster de servere Web. Pentru a configura acest mod trebuie precizat adresa IP i portul la care ascult serviciu. Acestea sunt specificate prin atributul stateConnectionString din elementul <sessionState> din fiierul de configurare. Obiectele salvate aici trebuie s fie serializabile. 3. SqlServer: A treia variant de pstrare a strii sesiunii este prin folosirea unui server SQL. Obiectele din sesiune trebuie s fie serializabile. n fiierul configurare trebuie precizat un connection string. Nu ntotdeauna este precizat numele bazei de date dei implicit este ASPState. n funcie de modul de operare: temporar (datele sesiunii sunt pierdute cnd serverul SQL este oprit) sau persistent n directorul de instalare al .NET Framework exist dou seturi de scripturi SQL (instalare i dezinstalare). Obiectul aplicaiei este similar i obiectul sesiunii pstreaz obiectele globale ntr-un dicionar. Fiecare valoare este reinut ca o referin de tip Object iar durata lor de via este dependent de cea a aplicaiei. n ceea ce privete gestionarea strii aplicaiei exist clasa HttpApplicationState din namespace-ul System.Web ce menine o colecie de obiecte globale comune tuturor clienilor. O alt variant de a declara variabile globale pentru aplicaie este de a aduga membri statici n clasa aplicaiei care este o clas derivat din HttpApplication. 150

Capitolul 8

Aplicaii ASP.NET

Cu toate c ASP.NET creeaz un obiect HttpApplication pentru fiecare cerere membrii static sunt comuni. Trebuie fcut observaia c aceti membri pot fi accesai n acelai timp de mai multe fire de execuie (corespunznd unui client) lucru ce implic crearea unui mecanism de excludere mutual. n continuarea acestui capitol va fi prezentat modul de creare i consumare a serviciilor Web XML implementate cu ASP.NET. 8.11 Introducere n serviciile Web Un serviciu Web poate fi privit ca o funcie util, accesibil prin Internet, ce poate fi utilizat ca o component n cadrul unei aplicaii, Web sau client. Serviciul este gzduit de un server Web i poate fi accesat de clieni incongrueni (ca i platform) prin intermediul unor standarde i protocoale comune: XML, WSDL, HTTP, SOAP, etc. Un serviciu Web mai poate fi privit ca o funcie de bibliotec n sensul utilizrii codului deja scris. Spre deosebire de un API ce poate fi folosit numai dac ntreaga bibliotec este copiat local, un serviciu Web este accesibil numai prin Internet iar codul se execut pe un server. Serviciile Web sunt urmtoarea generaie de componente distribuite i succed tehnologii precum DCOM sau CORBA aducnd urmtoarele avantaje n cadrul unei aplicaii distribuite: Simplitate: serviciile Web pot fi suportate de toate platformele ntruct folosesc protocoale cunoscute (open standards) global; Clientul nu este afectat dac definiiile funciilor din interfaa expus de serviciul Web sunt modificate, totui metodele trebuie s pstreze aceeai parametri i tip returnat; Un serviciu Web nu pstreaz starea i nici conexiunea creat pentru apelarea lui. Acest lucru ofer o scalabilitate ridicat ntruct poate rspunde la un numr mare clieni; ntruct folosesc HTTP i deci implicit portul de comunicaie este 80 sau 443 (HTTP Secure) acestea pot trece de firewall-uri; nainte de a construi o aplicaie distribuit bazat pe servicii Web i ASP.NET trebuie avute n vedere i celelalte variante de construire a sistemelor distribuite din .NET Framework. n cazul n care se dorete crearea unei aplicaii care s nu se limiteze numai la clieni .NET sau domeniul n care sunt vehiculate mesajele este considerat sigur (de exemplu ntre dou companii) atunci serviciile Web sunt o alegere bun. De asemenea, serviciile Web sunt indicate i n cazul cnd se dorete utilizarea unor facilitai oferite de ASP.NET (caching) sau de IIS (SSL i 151

Sisteme Distribuite

autentificare Windows) sau la crearea unei componente utilizabile ntr-o faz viitoare. Dac se dorete utilizarea funcionalitii ntre dou aplicaii .NET atunci serviciile Web nu constituie o soluie viabil ntruct cantitatea de date utile este comparabil cu cea de legtur i control (tag-urile XML induc un cost suplimentar ce afecteaz performana transmisiei datelor). O alternativ pentru utilizarea unei funcionaliti distribuite o constituie .NET Remoting. Acesta nu ofer acelai nivel de suport pentru standardele fr proprietar cum ar fi SOAP ns permite alegerea mai multor tipuri de comunicaie, tipuri din .NET, obiecte care i pstreaz starea i comunicaii TCP/IP mult mai eficiente. Singurul inconvenient este cel al dependentei de platforma .NET. 8.12 Standarde utilizate n serviciile Web Succesul serviciilor Web se datoreaz utilizrii standardelor fr proprietar. Utilizarea lor nu implic neaprat interoperabilitatea ntre sisteme eterogene. Interoperabilitatea este realizat n momentul n care exist un set de reguli valabile n orice sistem. Fiecare standard corespunde cte unui pas din procesul de apel al serviciului Web (vezi figura 8.5).
1- Localizeaz un serviciu XML http://www.uddi.org Link ctre un document WSDL sau DISCO

Director UDDI

Client serviciu Web

2- Cererea pentru descrierea unui serviciul web http://serviciuweb.com/?WSDL Document WSDL cu descrierea serviciului

3- Apel ctre metoda serviciului Web (SOAP) http://serviciuweb.com/serviciu1.asmx Rspuns (SOAP)

Serviciu Xml Web

Figura 8.5 Etapele i protocoalele folosite pentru un apel ctre un serviciu Web

Primul pas n utilizarea serviciului este gsirea sau localizarea lui. Acest pas poate fi opional dac serviciul Web apelat se gsete mereu la aceeai adres. n caz contrar dac adresa trebuie determinat n timpul 152

Capitolul 8

Aplicaii ASP.NET

execuiei aplicaiei sau se dorete o cale programatic prin care se pot obine toate referinele puse la dispoziie de un anumit site se utilizeaz un protocol de descoperire DISCO (discovery). Standardul DISCO creeaz un singur fiier ce grupeaz o list cu toate serviciile Web nrudite. O companie i public n acest fiier toate serviciile Web pe care le ofer. Clieni trebuie doar s cear acest document pentru a afl ce servicii sunt disponibile pe site-ul companiei. DISCO este un protocol proprietar i urmeaz a fi nlocuit n distribuiile urmtoare de .NET cu WS-Inspection. UDDI (Universal Description Discovery and Integration) este protocol de acces ntr-un director centralizat unde serviciile Web sunt publicate de ctre companii. Tot aici potenialii clieni pot cuta un serviciul Web. Organizaii diferite sau grupuri de companii pot utiliza registre diferite n cadrul UDDI. Dup ce am obinut o referin la un serviciu Web al doilea pas pentru un client este de a cunoate modul de a interaciona cu el adic: cunoaterea metodelor disponibile, a parametrilor i tipul lor. WSDL (Web Service Description Language) este un standard axat tot pe XML i creat pentru a descrie detaliile despre serviciul Web publicat. n tabelul (8-8) urmtor sunt prezentate principalele seciuni ale acestui document:
Tabel 8-8 - Seciunile din cadrul unui document WSDL
Seciune Types Messages Binding Service PortType Descriere n aceasta seciune sunt definite tipurile folosite de serviciu. Aceast seciune cuprinde informaii despre tipuri definite de utilizator i formatul mesajelor. Seciunea este destinat descrierii mesajelor de cerere i celor de rspuns. n aceasta seciune sunt pstrate informaiile despre protocoalele de transport suportate de serviciul Web. Seciunea conine informaii despre adresa URI al serviciului Web. Aceast seciune grupeaz mesajele n perechi intrare/ieire iar fiecare pereche reprezint o metod.

Al treilea pas pentru un client este comunicarea cu serviciul Web. Pentru a comunica este nevoie de a schimba mesaje. Mesajele trebuie s fie formatate astfel nct ambele pri s l neleag. Un astfel de formator de mesaje este SOAP (Simple Object Access Protocol), un limbaj bazat pe sintaxa XML. 153

Sisteme Distribuite

Este important de reinut ca SOAP definete modul n care sunt formatate mesajele i nu protocolul de transport. n ASP.NET serviciile Web folosesc pentru transport HTTP. Cu alte cuvinte pentru a interaciona cu un serviciu Web un client trebuie s deschid o conexiune HTTP i s trimit mesaje SOAP. .NET suport i metodele HTTP GET i HTTP POST pentru a comunica mesaje cu serviciului Web. Mesajele de aceast dat sunt colecii de perechi nume/valoare. Aceast metod este ntlnit adesea n paginile ASP.NET construite special pentru testarea serviciului Web. n continuare se va prezenta un exemplu simplu de serviciu Web ce realizeaz conversia ntre dou valute, un scenariu des ntlnit pe Internet ntruct cotaiile pentru fiecare moned pot varia de la zi la zi iar cursul valutar (vnzare/cumprare) este stabilit de fiecare banc n parte. n cazul n care o aplicaie Web folosete aceste informaii trebuie s acceseze serviciul Web pus la dispoziie de site-ul bncii. 8.13 Crearea unui serviciu Web Construcia unui serviciu Web ncepe de la o clas ce conine una sau mai multe metode. Cel puin una dintre aceste metode vor fi publicate i expuse prin interfaa Web a serviciului. n cazul exemplului nostru avem clasa Convert cu o singur metod ce va face parte din interfaa Web. Clasa are urmtoarea definiie (listing 8-3):
Listing 8-3 - Implementarea unui serviciu Web;definiia clasei serviciului Web public class Convert : System.Web.Services.WebService { float parityA2B = 10; // A/B public float CurrencyAtoB(float currencyA) { return currencyA * parityA2B; } } Obs: Proiectul din exemplele acestui capitol conine deja serviciul Web construit. Codul este separat de interfa iar directorul proiectului conine deja directoarele pentru o aplicaie Web App_Code i App_Data. Pentru a construi de la zero acest proiect trebuie creat un fiier surs *.cs n care se va introduce codul clasei mpreun cu o serie de atribute i modificatori i un fiier *.asmx pentru interfaa Web. Urmnd paii prezentai n continuare se vor putea completa aceste fiiere.

nainte de publica metoda CurrencyAtoB() trebuie verificat dac tipurile parametrilor formali i tipul returnat pot fi transformate conform regulilor standardului XML Schema, ntruct serviciile Web sunt construite 154

Capitolul 8

Aplicaii ASP.NET

pe baza standardelor XML. De aceea nu toate tipurile din .NET pot fi transformate n definiii de tipuri XSD. De exemplu tipuri precum Socket, Stream sau Form. Tipurile ce pot fi transformate automat ctre ASP.NET conform XML Schema sunt: tipuri valoare (value types), DateTime, enum, 1 XmlNode, DataSet, DataTable, iruri, tipuri generice i tipuri definite de utilizator cu observaia c numai tipurile suportate vor face parte din XSD. Dup cum se observ clasa Convert nu conine tipuri complexe i n consecin nu trebuie s ne preocupe acest aspect. Despre tipurile definite de utilizator vom discuta n ultima parte a capitolului. Pentru a transforma clasa Convert ntr-un serviciu Web tot ce trebuie fcut este s adugm atributul WebMethod n faa metodei CurrencyAtoB. Atributul se afl n namespace-ul System.Web.Services. n acest mod informm runtime-ul ASP.NET c metoda este disponibil pentru un apel remote (listing 8-4).
Listing 8-4 Decorarea metodei CurrencyAtoB() cu atributul [WebMethod]; acest lucru indic expunerea acestei metode pentru un apel remote [WebMethod] public float CurrencyAtoB(float currencyA) { return currencyA * parityA2B; }

Urmtorul pas l constituie expunerea serviciului n interfaa Web. naintea acestui pas nu exist nici o modalitate de executa codul metodei serviciului Web. Pentru permite apelul de pe Web al metodei, trebuie creat un fiier cu extensia .asmx care va expune pentru acces din afara serviciul Web. Fiecare fiier .asmx ncepe cu directiva WebService prin intermediul creia se declar limbajul folosit la scrierea codului (C#, J#, VB.NET ) , fiierul surs asociat i numele clasei serviciului Web. n exemplul urmtor se declar un serviciu Web cu avnd clasa Convert i codul este scris n C#:
<%@ WebService Language="C#" Class="Convert" %>

n acest punct exist dou opiuni: fie se insereaz codul clasei imediat dup directiv sau se poate compila fiierul *.cs, ce conine definiia clasei, ntr-un assembly iar apoi acesta s fie mutat n directorul Bin. O alt modalitate ar fi copierea fiierului surs n directorul cunoscut de ASP.NET, App_Code, pentru a beneficia de compilarea automat. Ca i n cazul Web Form-urilor codul poate fi plasat n fiierele de interfaa Web (pentru Web Forms fiierele *.aspx). Plasarea codului pentru un serviciu Web direct n fiierul .asmx duce la apariia unor probleme. Mai nti codul este compilat
1

ncepnd cu .NET Framework 2.0

155

Sisteme Distribuite

abia n momentul primei cereri ceea ce poate genera neajunsuri deoarece testarea codului (chiar i pentru mici greeli de tastare) se face doar la compilare. n al doilea rnd, mediul Visual Studio nu recunoate fiierele .asmx ca i fiiere ce conin cod i ca atare, nu ofer colorarea sintaxei i serviciul de IntelliSense. ASP.NET ofer posibilitatea descrierii serviciului Web i a fiecrei metode n parte. Acest lucru este se poate dovedi util pentru clienii noi ai unui serviciu Web. Documentarea se face prin decorarea cu atribute att clasei ct i a metodelor acesteia.
Obs: Dac se vizualizeaz coninutul fiierului .asmx generat de Visual Studio se poate observa un atribut CodeBehind: <%@ WebService Language="C#" CodeBehind="~/App_Code/Convert.cs" Class="Convert" %> Din nefericire acest atribut poate fi uor confundat cu o locaie spre codul surs dei documentaia MSDN indic clar la acest lucru. n realitate acest atribut este folosit doar de ctre Visual Studio pentru a documenta faptul ca fiierul .asmx are un fiier code-behind. ASP.NET ignor acest atribut iar tipul din atributul Class este luat din assembly-ul rezultat prin cele dou modaliti prezentate mai sus.

Informaiile precizate n descriere vor fi prezente i n documentul WSDL. Clasa din exemplu anterior va arata n felul urmtor (listing 8-5):
Listing 8-5 Adugarea unei descrieri pentru serviciului Web [WebService(Description="Serviciu Web pentru conversia valutelor", Name="ConversiiValute" , Namespace = "ConversiiValute")] public class Convert : System.Web.Services.WebService { float parityA2B = 10; // A/B [WebMethod(Description="Metoda pentru conversia din valuta A n B")] public float CurrencyAtoB(float currencyA) { return currencyA * parityA2B; } }

nainte de a trece la testarea aplicaiei trebuie fcut urmtoarea observaie: atunci cnd se utilizeaz Visual Studio pentru crearea de servicii Web, automat clasa este derivat din WebService. Trebuie menionat c nu derivarea din aceasta clas contribuie la crearea serviciului Web ci atributul WebMethod ataat metodelor propuse spre expunere. Derivarea ofer 156

Capitolul 8

Aplicaii ASP.NET

posibilitatea accesrii obiectelor predefinite din ASP.NET: Application, Session, User, Context i Server. Dac se renun la derivare aceste obiecte pot fi accesate prin proprietatea static oferit de clasa HttpContext.Context ce returneaz contextul curent al strii aplicaiei.

Figura 8.6 Pagina de test pentru serviciul Web dat ca exemplu

Testarea serviciului Web se face folosind un browser Web n care introducem adresa ctre fiierul .asmx. n browser va apare o pagin de test generat, de runtime-ul ASP.NET, aa cum se poate vedea n imaginea din figura 8.6. 8.14 Tranzacii Serviciile Web ca orice alt aplicaie .NET pot realiza tranzacii. De asemenea serviciile Web pot participa i n tranzacii COM+. Acestea folosite mpreun cu bazele de date ofer posibilitatea utilizrii mai multor surse de date diferite (de exemplu o baz de date SQL Server i una Oracle). Tranzaciile COM+ pot face commit sau rollback automat. Preul pltit pentru aceste funcionaliti este acela c sunt mult mai lente dect cele folosite n ADO.NET sau cele bazate pe proceduri stocate. Funcionarea lent se datoreaz protocolului de commit n dou faze [Mac05]. n ceea ce privete serviciile Web, se mai poate adaug faptul c suportul tranzaciilor COM+ este limitat. Din cauza c protocolul HTTP nu permite pstrarea strilor ntre apeluri, metodele Web acioneaz ca o singur rdcin n cadrul tranzaciei. Cu alte cuvinte dou sau mai multe metode ale serviciului Web nu pot fi grupate n cadrul aceleiai tranzacii. De aceea metodele trebuie adunate ntr-una singur ce va constitui rdcina tranzaciei [Mac05]. 157

Sisteme Distribuite

Pentru a folosi tranzacii n cadrul serviciului Web trebuie adugat namespace-ul System.EnterpriseService iar pentru a ncepe o tranzacie metoda rdcin trebuie decorat astfel (listing ):
Listing 8-6 Decorarea unei metode ce iniiaz o tranzacie [WebMethod(TransactionOption=TransactionOption.RequiresNew)] public WebTransacMethod() { .. }

Trebuie menionat c tranzacia eueaz atunci cnd n metoda serviciului Web apare o excepie netratat sau dac se decide explicit acest lucru prin apelul metodei statice ContextUtil.SetAbort(). 8.15 Consumarea unui serviciu Web nainte de a folosi un serviciul Web clientul trebuie s poat trimite, s primeasc mesaje i cel mai important s neleag formatul acestor mesaje. n acest sens .NET conine o component numit proxy ce realizeaz operaiile de codarea i decodarea a mesajelor n format SOAP i trimiterea i recepionarea lor. O clas proxy poate fi generat n dou moduri: - folosind utilitarul wsdl.exe; - folosind wizard-ul din Visual Studio de adugat referine Web. Ambele variante produc rezultate asemntoare ntruct folosesc aceleai clase din namespace-ul System.Web.Services. Pornind de la aceste clase se poate genera programatic clasa proxy.
Obs: Documentul WSDL pentru serviciul Web dat drept exemplu poate fi vizualizat n browser adugnd dup URL serviciului parametrul ?WSDL.

n cazul n care clasa proxy este generat de la linia de comand trebuie menionat ca utilitarul wsdl.exe se gsete n directorul de instalare a Visual Studio sau al SDK-ului .NET. Instrumentul ateapt ca parametru un URL ctre serviciul Web sau o cale ctre un document WSDL sau o schem XSD sau un fiier discomap. n exemplul urmtor de utilizare se precizeaz un URL:
wsdl http://localhost/Currency/Convert.asmx

Implicit se genereaz cod C# ns se poate specifica limbajul dorit n rezultat utiliznd parametrul /language:{CS|VB}. Fiierul surs creat are 158

Capitolul 8

Aplicaii ASP.NET

implicit numele serviciului Web. Numele acestui fiier se poate preciza prin parametrul /out:nume_fiier. A dou modalitate de generare a clasei proxy implic folosirea opiunii Add Web Reference din Visual Studio. Spre deosebire de wsdl.exe acest instrument are o interfaa grafic i adesea este mult mai uor de folosit. Atunci cnd se adug o referin Web la un proiect .NET, Visual Studio salveaz o copie a documentului WSDL n directorul proiectului. Directorul n care este salvat efectiv depinde de tipul aplicaiei. ntr-o aplicaie Web este salvat n App_WebReferences, sub un director cu numele precizat n interfaa grafic a instrumentului de adugare de referine Web, mpreun cu toate fiierele adiionale pentru acest serviciu. Trebuie menionat c nu se genereaz codul proxy-ului, n schimb acesta este construit n timpul procesului de compilare1. n orice alt tip de aplicaie Visual Studio creeaz un director WebReferences i un subdirector cu numele precizat de asemenea n Add Web References. n interiorul subdirectorului sunt plasate: documentul WSDL, un fiier Reference.cs ce conine definiia clasei proxy i alte fiiere adiionale. Clasa proxy generat pentru exemplul anterior poate fi urmrit n listingul urmtor (listing 8-7). Trebuie precizat c instrumentul de crearea a clasei proxy adug membrii i i decoreaz atributele specifice. Codul urmtor reprezint versiunea simplificat a clasei proxy:
Listing 8-7 Clasa proxy pentru serviciu Web dat anterior ca exemplu public partial class ConversiiValute : System.Web.Services.Protocols.SoapHttpClientProtocol { public ConversiiValute() { this.Url = global::ConvertClient.Properties.Settings.Default.ConvertClient_localhost_Conversi iValute; } public float CurrencyAtoB(float currencyA) { object[] results = this.Invoke("CurrencyAtoB", new object[] {currencyA}); return ((float)(results[0])); } public void CurrencyAtoBAsync(float currencyA) {} public void CurrencyAtoBAsync(float currencyA, object userState) { this.InvokeAsync("CurrencyAtoB", new object[] { currencyA}, this.CurrencyAtoBOperationCompleted, userState); } public new void CancelAsync(object userState) {}
1

Acest comportament este specific pentru ASP.NET 2.0

159

Sisteme Distribuite

private bool IsLocalFileSystemWebService(string url) {} private System.Threading.SendOrPostCallback CurrencyAtoBOperationCompleted; }

n legtur cu proxy-ul generat trebuie fcute dou observaii. Prima este c pe lng metode sincrone (blocante pentru firul curent) clasa ofer suport i pentru apel asincron de metode. A doua se refer la modelul de programare asincron utilizat: n versiunile anterioare de ASP.NET se folosea modelul ce avea la baz interfaa IAsynResult adic pentru fiecare metod Web se genera cte o pereche metode BeginMetoda i EndMetoda iar n ASP.NET 2.0 se utilizeaz modelul bazat pe evenimente. Pentru detalierea celor dou modele se pot reciti conceptele .NET discutate n capitolul 2. Trebuie fcut observaia c namespace-ul n care se afl clasa proxy depinde de numele serviciului Web dat n instrumentul Add Web Reference: dac se utilizeaz numele implicit atunci cel mai probabil namespace-ul va fi NamespaceProgram.NumeServiciu unde NamespaceProgram este numele namespace-ului implicit utilizat n program. Codul pentru invocarea metodei serviciului Web dat ca exemplu este urmtorul (listing 8-8):
Listing 8-8 Invocarea serviciului Web dat ca exemplu n acest capitol using System; using ConvertClient.localhost; namespace ConvertClient { class Program { static void Main(string[] args) { ConvertClient.localhost.ConversiiValute conversie = new ConversiiValute(); Console.WriteLine(" {0} A valoreaza {1} B",100, conversie.CurrencyAtoB(100)); } } }

8.16 Transmiterea tipurilor definite de utilizator Pn n acest moment exemplul de serviciu Web folosea tipuri simple de date. Dac ns dorim s returnm tipuri definite de utilizator ? Cu ajutorul clasei XmlSerializer, serviciile Web ofer un mecanism facil de transmitere a tipurilor particularizate. 160

Capitolul 8

Aplicaii ASP.NET

Pentru a ilustra acest lucru n continuare va fi analizat un serviciu Web ce vehiculeaz obiecte ale unei clase ce reprezint un angajat dup cum se observ mai jos (listing 8-9).
Listing 8-9 Definiia unui serviciu Web ce transmite un tip specializat //serviciul Web public class EmployeeService : System.Web.Services.WebService { [WebMethod] public EmployeeData GetEmployee(int Id) { return new EmployeeData(Id, "Homer", "333-33-3333"); } } //tip specializat public class EmployeeData { public string Name; public string SSN; [XmlAttribute()] public int Id; public EmployeeData(int id, string name, string ssn) { Id= id; Name = name; SSN = ssn; } public override string ToString() { return string.Format("ID={0};Name={1};SSN={2}", Id, Name, SSN); } //cerut de XmlSerializer public EmployeeData(){} } } Obs: - metoda unui serviciu Web ntoarce valori i parametri de ieire doar prin valoare. - un serviciu Web folosete pentru serializarea obiectelor XmlSerializer din namespace-ul System.Xml.Serialization.

Cnd un client apeleaz metoda EmployeeService.GetEmployee(), XmlSerializer serializeaz obiectul returnat EmployeeData n urmtorul document XML (listing 8-10):
Listing 8-10 - Serializarea unui obiect de tip EmployeeData, tip definit n listingul 8-9 <?xml version="1.0" encoding="utf-8" ?> <EmployeeData xmlns:xsd="http://www.w3.org/2001/XMLSchema"

161

Sisteme Distribuite

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xmlns=http://tempuri.org/ Id="2" > <Name>Homer</Name> <SSN>333-33-3333</SSN> </EmployeeData>

Ca s deserializeze obiectul din listingul anterior clientul trebuie s tie structura tipului EmployeeData. Aceast informaie poate fi preluat din contractul WSDL ataat serviciul Web. Folosind documentul WSDL,Visual Studio (prin instrumentul wsdl.exe) se genereaz un tip de date pe partea de client pentru a reprezenta obiectul EmployeeData (listing 8-11).
Listing 8-11 - Definiia clasei EmployeeData generat de instrumentul wsdl.exe pe baza contractului WSDL public class EmployeeData { public string Name; public string SSN; [System.Xml.Serialization.XmlAttributeAttribute()] public int Id; [System.Xml.Serialization.XmlIgnoreAttribute()] public bool IdSpecified; }

Observm c implementarea pe partea de client nu include nici una din metodele definite mai sus (listing 8-9) pentru clasa EmplyeeData. Spre deosebire de metadata generat de instrumentul soapsuds pentru .NET Remoting, metadata serviciilor Web nu include informaii legate de metode ci doar informaii referitoare la starea obiectului. Clientul poate folosi clasa EmployeeData generat pentru a obine doar cmpurile de date. 8.17 Transmiterea tipurilor generice Pentru a exemplifica aceast tehnic s presupunem c avem o ierarhie de clase a angajailor cu EmployeeData fiind clasa cea mai de sus i dou clase derivate denumite WageEmployee i Boss. Pentru verificare vom include de asemenea o metod polimorfic ComputePay(). Definiiile acestor tipuri sunt urmtoarele (listing 8-12):
Listing 8-12 - Definitiile claselor EmployeeData,WageEmployee si Boss public abstract class EmployeeData { public string Name; public string SSN;

162

Capitolul 8

Aplicaii ASP.NET

[XmlAttribute()] public int Id; public EmployeeData(int id, string name, string ssn) { Id = id; Name = name; SSN = ssn; } public override string ToString() { return string.Format("ID={0};Name={1};SSN={2}", Id, Name, SSN); } public abstract double ComputePay(); public EmployeeData(){} } public class WageEmployee : EmployeeData { public double Wage; public double Hours; public override double ComputePay() { return Wage * Hours; } WageEmployee(int id, string name, string ssn) : base(id, name, ssn) {Wage = 10; Hours = 40;} public WageEmployee(){} } public class Boss : EmployeeData { public double Salary; public override double ComputePay() { return Salary; } Boss(int id, string name, string ssn): base(id, name, ssn) {Salary = 9999; } public Boss(){} }

n continuare vom modifica metoda GetEmployee() a serviciului Web astfel nct s creeze i s returneze un obiect Boss dac ID-ul este 1 i n celelalte cazuri s returneze un obiect WageEmplyee (listing 8-13):
Listing 8-13- Serviciul Web ce vehiculeaz tipurile definite n listingul 8-12 public class EmployeeService : System.Web.Services.WebService { [WebMethod] public EmployeeData GetEmployee(int Id) { if (Id == 1) { return new Boss(Id, "Marge", "333-33-3333"); } else { return new WageEmployee(Id, "Homer", "444-44-4444"); } }

Interesant n acest exemplu este faptul c metoda GetEmployee() returneaz tipul generic EmployeeData. Din moment ce acesta este singurul 163

Sisteme Distribuite

tip expus lumii exterioare, ASP.NET nu include subclasele atunci cnd genereaz contractul WSDL i, de aceea, clienii nu le vor recunoate la returnare. Ca rezultat, atunci cnd executm codul clientului vom obine o excepie. Pentru a preveni acest lucru trebuie s specificm n mod explicit includerea definiiile pentru Boss i WageEmployee n contractul WSDL. Putem realiza acest lucru trebuie s adugam clasei EmployeeData atributul XmlInclude, aa cum se observa mai jos (listing 8-14):
Listing 8-14 - Adaugarea atributului XmlInclude pentru a specifica tipurile compatibile [XmlInclude(typeof(WageEmployee)), XmlInclude(typeof(Boss))] public abstract class EmployeeData { ... }

De fiecare dat cnd runtime-ul ASP.NET genereaz WSDL pentru acest serviciu Web, el va include i definiiile pentru tipurile Boss i WageEmployee. Tem 1. Realizai un serviciu Web i un client care s vehiculeze clase de tip Employee. Serviciul Web trebuie s permit vehicularea obiectelor acestei clase i a celor cu tipuri derivate din ea. Interfaa serviciului Web s fie urmtoarea:
void AddManager(Employee e); void AddEmployee(Employee m, Employee e); Employee GetManagerOf(Employee e); Employee GetEmpoyeesOf(Employee manager);

2. Creai un serviciul Web care efectueaz modificri asupra unei baze de date. Clientul de test al serviciului va fi implementat sub forma unei aplicaii Web. Serviciul trebuie s foloseasc tranzacii. Testai dac modificrile sunt realizate n baza de date n cazul apariiei unei excepii netratate.

164