Server Web IIS 7.0 din Windows – Modificări de arhitectură

Să mă țin de cuvânt. Când am început să vorbesc despre configurarea serverului de Web Microsoft IIS 7.0, promiteam să revin cu ceva detalii despre schimbările arhitecturale față de versiunea anterioară, Internet Information Services 6.0 din Windows XP și Windows Server 2003.

IIS 7.0 din Windows Vista și Windows Server 2008 nu este doar platformă de aplicații; se vrea și un server de Web pentru cei care furnizează servicii de hosting. Ei bine, tocmai modificarea arhitecturii la IIS 7.0 a permis adăugarea acelor facilități ce ajută în găzduirea de multiple site-uri sau aplicații pe același server.

Arhitectura IIS 6.0 din Windows XP și Windows Server 2003 IIS 6.0 împreună cu ASP.NET

Pe vremea IIS 6.0

IIS 6.0 avea o structură monolitică, cu toate limitările ce decurgeau de aici. Pentru că serverul de web nu prea putea fi ușor modificat, funcționalitatea era oarecum rigidă.

De fapt, dacă voiai să adaugi sau să modifici funcționalitate la IIS 6.0, o făceai la nivelul ISAPI. Ceea ce aducea din start o problemă: dacă programai la nivelul ISAPI, nu prea aveai cum să te legi de funcțiile de autentificare sau logging ale serverului de web, bunăoară. Faza tare e că echipa de dezvoltare a IIS din Redmond nu acționa la nivelul ISAPI pentru a adăuga funcționalitate în IIS. Mergea uneori pe alte nivele, paralele. Cu consecința că o actualizare a IIS-ului era realizabilă doar odată cu lansarea unei noi versiuni de sistem de operare🙂

ASP.NET era implementat și el la fel: ca filtru și aplicație ISAPI – vezi figura din casetă. Dacă te uiți atent, vezi că mai apare o problemă: o parte din funcțiile ASP.NET – cum ar fi mecanisme de autentificare – le duplicau pe cele de la nivelul serverului de Web.

Una peste alta, ASP.NET funcționa cu serverul de Web, dar nu foarte bine integrat. Și nici nu puteai să extinzi după nevoi server-ul de Web modificând parte din modulele sale. Hai să vedem ce s-a schimbat odată cu lansarea Windows Vista…

Vremuri noi cu IIS 7.0

Arhitectura IIS 7.0 din Windows Vista și Windows Server 2003 ASP.NET în IIS 7.0
(Integrated Mode)

Microsoft a inclus noua versiune IIS 7.0 în Windows Vista, așa cum ne așteptam. O nouă versiune a serverului de Web IIS este prima dată înclusă în Windows-ul pentru desktop-uri, pentru validarea de către utilizatori, și abia apoi în Windows-ul pentru servere.

Dacă ne uităm la arhitectura IIS 7.0… Ooops! Diversele funcționalități din IIS au devenit module ce s-au așezat de-a lungul ciclului de procesare, conectate la diversele stadii ale benzii de deservire. Nu mai sunt parte dintr-o structură monolitică.

Abordarea asta permite și echipei de dezvoltare IIS din Redmond să adauge funcționalități noi între lansări de versiuni. Un exemplu: serviciul FTP a fost rescris și publicat la ceva timp după ce se lansase Windows Server 2008 – vezi site-ul iis.net.

Banda de deservire (sau request pipeline) este una mică și generică. Modulele pot fi "înfipte" sau "scoase" din etapele cererii. Putem realiza servere ușurele (lightweight) cu doar acele module ce ne sunt necesare. Sau, mai mult, putem să modificăm sau să realizăm noi propriile noastre module pe care să le dispunem de-a lungul țevii, capturând și tratând diversele evenimente ce se petrec pe drumul devenirii unei cereri în răspuns. Ce texte am în mine🙂

Funcții din ASP.NET s-au aliniat și ele ca module de-a lungul țevii, tratând evenimente declanșate de diverse etape ale vieții unei cereri. Este paradigma Integrated Mode. Există și un Classic Mode, în care ASP.NET funcționează cum o făcea cu IIS 6.0.

Module versus mânere. Extensibilitate prin .NET. Câteva idei pentru codăi

Mâner este traducerea mea pentru handler din engleză. Codău este tipul care scrie cod, adică dezvoltator sau programator. Nu vreau sa jignesc pe nimeni, ci doar fac spirite🙂 Și eu aspir la condiția de codău, mai scriu și eu progrămele, dar sunt, din păcate, departe de a fi un dezvoltator.

Să revin: modules versus handlers. Modulele sunt cele ce asigură servicii pentru toate cererile. De exemplu, autentificare sau compresie; indiferent ce fișier ceri server-ului de Web, cererea trece prin autentificare și eventual compresie. Prin contrast, un handler se referă la o anumită extensie; există static handler pentru fișiere .htm, .jpg, .gif sau mânere dinamice pentru .aspx, .php etc.

Extinderea funcționalității serverului de Web se realizează prin adăugarea (sau modificarea) modulelor sau mânerelor. În Windows SDK m-aș uita după implementarea interfețelor IHttpModule sau IHttpHandler. Bineînțeles că veți ajunge în situația de a trata evenimente ce apar pe parcursul benzii de deservire. Iar atunci când faci noi module, așa cum a făcut echipa IIS cu FTP, probabil vei dori și o modalitate de administrare a acelor module – ei bine, poți să extinzi inclusiv consola de management a IIS pentru asta (cred că m-aș uita la IIS 7.0 SDK).

Despre arhitectura IIS 7.0 și extensibilitate prin .NET scriu alții mult mai bine decât mine. Eu recomand screencast-ul ăsta de pe site-ul iis.net și eventual articolul despre arhitectură de aici. Există și un articol despre cum dezvolți un modul IIS 7.0 cu .NET. Un nene scrie pe blogul lui pe scurt despre evenimentele de-a lungul benzii de deservire, dar parcă și mai bine documentată este pagina de pe MSDN despre nașterea, trăirile, tresăririle și devenirea întru răspuns a unei cereri în ASP.NET.

Lasă un răspuns

Completează mai jos detaliile despre tine sau dă clic pe un icon pentru autentificare:

Logo WordPress.com

Comentezi folosind contul tău WordPress.com. Dezautentificare / Schimbă )

Poză Twitter

Comentezi folosind contul tău Twitter. Dezautentificare / Schimbă )

Fotografie Facebook

Comentezi folosind contul tău Facebook. Dezautentificare / Schimbă )

Fotografie Google+

Comentezi folosind contul tău Google+. Dezautentificare / Schimbă )

Conectare la %s