B U D A P ES TI MŰSZ A KI ÉS G A Z D A S Á G T U D O M Á N YI E G Y E T E M
M i c r o s o ft . N et k e r etre n d s z e r i s m e rteté s e I n f o r m ati k a I. H á z i fel a d at K é s z ítette: K o v á c s R o l a n d – S 2 3 9 N Q 2009.03.07.
[ I d e ír h atja b e a d o k u m e nt u m k i v o n atát, a m e l y re n d s z e ri nt a d o k u m e nt u m r ö v i d ö s s z e f o g l a l á s a. I d e ír h atja b e a d o k u m e nt u m k i v o n atát, a m e l y re n d s z e ri nt a d o k u m e nt u m r ö v i d ö s s z e f o g l a l á s a. ]
Bemutatkozik a Microsoft .Net A számítástechnika és az alkalmazásfejlesztés világában szinte lehetetlen a hatékony szoftverfejlesztés egy megfelelő ’magasabb rendszer’ megléte nélkül. Vegyünk egy sokkal hétköznapibb példát ennek belátására és szükségességének átérzésére. Nem magunk építjük a közutakat, amelyben kocsinkkal furikázunk, és az áramfejlesztő berendezéseinket sem magunk telepítjük. Szerencsére az alkalmazásaink infrastruktúra igénye éppúgy ugyanolyan, hasonló minden embernél, mint az utak és a közlekedésstruktúra iránti igény. Az ilyen nagy közös igények miatt építenek a kormányok közutakat, és az áramszolgáltatók nagy erőműveket, amelyeket aztán díjak fejében használhatnak az állampolgárok. A kormányok és közművek sok pénzt és erőfeszítést takaríthatnak meg, mert a célok eléréséhez a leghozzáértőbb szakértőket alkalmazhatják és képezhetik ki, és a fejlesztés költségeit sokkal több részre oszthatják szét. Amire valójában szükség van , hogy valaki vagy valami az elosztott számítástechnikában megtegye azt, amit a kormány az országutak építésekor. A fejlesztőknek szükségük van egy ’felsőbb hatalomra’, egy ’ magasabb rendszerre’ , aki biztosítja az internetes infrastruktúrát, valamint az egységes és kényelmesebb életet számukra. A Microsoft .Net pontosan ez : egy előregyártott infrastruktúra az internetes alkalmazásokban jelentkező problémák megoldására. Ennek köszönhetően a Microsoft .Net 2000-es megjelenése óta egyre nagyobb figyelmet kapott. Az év végére elkészült az első béta változat, 2002. január 5-én pedig a .NET Framework 1.0 verziója végre a nagyközönség kezei közé került.
Tartalomjegyzék : 1.
2.
3.
A .Net objektumok •
A probléma háttere
•
A megoldás áttekintése
•
Az assembly
•
Memóriakezelés
•
Együttműködés a COM-mal
•
COM objektumok használata a .Net-ből
•
Tranzakciók a .Net-ben
•
Strukturált kivitelezés
•
A hozzáférés szabályozása
Az ASP.Net •
A probléma háttere
•
A megoldás áttekintése
•
Webes vezérlőelemek
•
Állapotkezelés az ASP.NET-ben
•
Biztonság az ASP.NET-ben
•
Hitelesítés és engedélyezés
A .Net webszolgáltatások •
A webszolgáltatások létrejöttének okai
•
A probléma háttere
•
A megoldás
1.
A .Net objektumok
A .Net keretrendszer (.NET framework) olyan futtatási környezet, amely lehetővé teszi, hogy programozók könnyen és gyorsan írjanak jó és robosztus programokat, és segíti a programkód felügyeletét, telepítését és felülvizsgálatát is. A fejlesztők által írt programok és komponensek e kereten belül futnak. A .Net keretrendszer remek futtatási szolgáltatásokat nyújt : pl. automatikus memóriakezelés és vele egyszerűbben elérhetők a rendszerszolgáltatások is. Több kisegítő szolgáltatással is rendelkezik : ide tartozik az az egyszerű internet- és adatbázis hozzáférés. A keretrendszer a programkód újrafelhasználására is újfajta mechanizmust alkalmaz – egyszerűbben használható, ugyanakkor nagyobb teljesítményű és rugalmasabb, mint pl.: a COM. A .Net keretrendszeren belül egyszerűbb az alkalmazások telepítése, mert nem igényel beállításokat a rendszerleíró adatbázisban. Ráadásul szabványosított, rendszerszintű verziókezelést is támogat. Ezeknek a szolgáltatásoknak mindegyike elérhető az összes .Net-kompatibilis programozási nyelvben.
1. 1
A probléma háttere
Mint a legtöbb szoftverarchitektúra, a COM is egy bizonyos pontig segít, belső szerkezete viszont immár akadályt, nem segítséget jelent. A COM két legfőbb problémája a következő : • minden alkalmazásban szilárd infrastruktúrára van szükség, pl : osztálygyárakra és illesztési programcsomagolókra. Mind a fejlesztői környezetben meg kell valósítani ezeket a mechanizmusokat, így azok mindig kissé különböznek egymástól, nem kompatibilisek annyira egymással, mint mi az szeretnénk.
a COM az ügyfelet és a kiszolgálót tisztes távolságban tartja. Egymással külső illesztőfelületeken érintkeznek, nem pedig belső megvalósításukon keresztül. Sajnos az összes COM-illesztőfelület megvalósítása különbözik alig észrevehető, de nehezen összehangolható módon. A karakterláncokat máshogy kezeli minden programnyelv. Ha a Visual Basicben írt COM-kiszolgálótól egy karakterláncot akarunk átadni a C++-ban írt COM-ügyfélnek, valakinek el kell simítania a különbségeket, méghozzá általában a C++ alkalmazásnak. A programozók aránytalanul sok időt töltenek az ehhez hasonló különbségek elsimításával. Szeretnék ha egy szoftvert elég lenne egyszer megírni ahhoz, hogy minden rendszeren fusson. A jövőben ezt lehetne fejleszteni, a szoftverarchitektúrák rendszerek közötti együttműködését. •
Biztosítani kell valamint egy szoftver piacra kerülése után a frissítések kompatibilitását minden korábbi és tetszőlegesen frissített rendszer esetére. Olyan szabványos mechanizmusra van szükség, amely segítségével a kiszolgálók közzétehetik saját verziószámukat. E mechanizmus segítségével az ügyfelek kiolvashatnák a rendelkezésükre álló kiszolgálók verziószámát, és kiválaszthatnának közülük egy olyant, amellyel kompatibilisek, vagy ha ez nem lehetséges, egyértelműen azonosíthassák, milyen műveleteket nem fognak tudni elvégezni.
1.2 A megoldás áttekintése A .Net-keretrendszer a Microsoft operációsrendszer-szintű terméke, és előregyártott megoldásokat ad a fenti programozási problémákra. A keretrendszer kulcsa a felügyelt kód. A felügyelt kód a CLR-nek (Common Language Runtime, nyelvek közös futtatórendszere) nevezett környezetben fut, ahogy ezt a 1.2.1 ábra is mutatja. Felügyelt kód C L R nyelvfüggetlen futtatórendszer L é t e z ő m ű v e l ete k (f ájl m e g n y itá s ) e l v é g z é s e C L R k ö z v etité s é v e l Operációs rendszer
Ú j , c s a k a C L R által s z o l g á ltat ott m ű v e l ete k, p é l d á u l a s z e m ét g y ű jté s
1.2.1 ábra : Felügyelt programvégrehajtás a CLR-ben Ilyen architektúra mellett hogyan tud a CLR bármely nyelvvel együttműködni ? Minden CLR-kompatibilis fejlesztőeszköz a forráskódot a 1.2.2 ábra szerint a szabványos MSIL (Microsoft Intermediate Language – Microsoft közbenső nyelv) nyelvre fordítja le.
F o rrás k ó d : V i s u al B a s i c , C++, C o b o l st b.
JIT forditó
M SIL
K ü r n y e z et s p e c ifi k u s f uttat hat ó k ó d
1.2.2 ábra : A különböző programozási nyelvekben megirt forráskódokat a gép mind MSIL-re fordítja le Mivel a fejlesztőeszközök az MSIL-re forditanak, a forráskód nyelvétől függetlenül eltűnnek a belső megvalósítási különbségek, mielőtt elérnék az CL R-t. Ez azért van, mert minden program a string objektumot használja. Ugyanez igaz a tömbökre, osztályokra és minden egyébre. A fejlesztőeszköz által létrehozott MSIL kód közvetlenül nem futtatható egyetlen számítógépen sem. Szükség van, ahogy a 1.2.2 ábra is mutatja egy második lépésre, az un. JIT (just in time – futtatás előtti) fordításra. Ez a JIT fordító beolvassa az MSIL-t és az adott rendszeren futtatható gépi kódot készít belőle. Ezzel a .Net rendszer bizonyos mértékig rendszerfüggetlenné válik, mivel minden rendszerre lehet külön JIT fordítót irni. A .Net keretrendszer a szemétgyűjtés (garbage collection) nevű mechanizmus révén valósítja meg az automatikus memóriakezelést. A programoknak a lefoglalt memóriát tételesen fel kell szabadítaniuk. A CLR észleli, ha a program a memóriát már nem használja, és automatikusan újrahasznosítja. A .Net keretrendszer támogatja a verziókezelést is, valamint szabványosítja, hogy hogyan adhatják meg a kiszolgáló-fejlesztők az .EXE és .DLL fájlok verziószámát. Az is szabványosításra kerül, hogy az ügyfelek milyen szabványos mechanizmus alapján határozhatják meg a számukra szükséges verziószámot. Tartalmaz alapértelmezett verziókezelést is, de azt is lehetővé teszi, hogy a fejlesztők ezt felülbírálják.
Mivel minden nyelv forráskódja azonos típusú MSIL kóddá alakul át, a CLR-t támogató bármely egyforma szolgáltatás halmaz kezelésére képes. A CLR az öröklés és paraméterezett objektumkonstruálás mellett még sok objektumorientált programozási eljárást támogat. A .Net keretrendszer az operációs rendszer funkcióit a rendszertérbe, a system névtérbe helyezi. Az operációs rendszer minden objektuma, illesztőfelülete és függvénye immár hierarchikus rendszert alkot. Ez biztosítja, hogy a saját objektum- és függvénynevek ne ütközzenek más felhasználók által használt nevekkel. A .Net keretrendszer támogatja a kód hozzáférés-szabályozást is. Megadhatjuk, hogy a kódrészlet mely programrészletre lehet jogosult és melyre nem. Beállithatjuk, hogy a kód olvashat, de nem írhat fájlokat, a CLR pedig gondoskodik ennek betartásáról. Ha a kód mégis megpróbál fájlokat írni, a CLR blokkolja a műveletet. A .Net keretrendszer tökéletes együttműködést biztosit a COM-mal, mind az ügyfelek, mind a kiszolgálók számára. A .Net kód nem tudja, hogy milyen objektummal működik együtt, de ez nem is érdekes számára. 1.3
Az assembly
A .Net keretrendszer a .Net kód, az erőforrások, és az adatok tárolására széles körben alkalmazza az assemblyket. A .Net futtatórendszer csak az assemblyben tárolt kódot hajtja végre. Ezen felül minden biztonsági funkció, név-feloldás és verziókezelés az assemblyk szintjén valósul meg.
1.3.1 Az assembly elv Az assembly az alkalmazás kódját és erőforrásait tartalmazó .EXE vagy DLL fájlok logikai gyűjteménye. Az assembly önleíró kódokat, ún. manifesztet is tartalmaz, amely az assemblyben található kód és erőforrások leírása adatok formájában. Az asselmbly gyakran egyetlen fájl, mint ahogyan azt az 1.3.1 ábra is mutatja.
Az assemblyk tipusai E g y f áj l o s a s s e m b l y
T ö b b f áj l o s a s s e m b l y
b o o. dll m o o. dll
gra p hi c.jp g
l o g o. b m p
m a n i f e s zt
m a n i f e s zt
1.3.1 ábra : Egy és többfájlos assemblyk m a n if e s zt
Bár az assembly gyakran egy fájlban található, nem ritka eset, hogy a 1.3.1 ábrán látható módon az assembly több, azonos könyvtárban található fájl logikai (és nem fizikai !!) gyűjteménye. Az assemblyt alkotó fájlokat leíró manifeszt vagy az assembly egyik EXE vagy DLL állományában található, vagy pedig maga külön alkot egy EXE vagy DLL fájlt. Ha többfájlos assemblyvel állunk szemben, sose felejtsük el, hogy a fájlok között semmilyen fizikai kapcsolat nincs. Csupán attól részei az assemblynek, hogy szerepelnek a manifesztben. (Az assembly szó egyébként szerelvényt jelent, de szerencsésebb, ha mint névsor gondolunk rá.)
1.3.2 Az assemblyk és (szét)telepítésük A programkód assemblykre osztásával kapcsolatban központi kérdés, hogy az assemblyn belüli kódot csak a saját alkalmazás használja-e, vagy külső alkalmazások is. A Microsoft .Net mindkét lehetőséget támogatja, de a második több munkát igényel. A saját alkalmazások számára írott kód, mondjuk a
pénzügyi számítási program modulja esetében valószínűleg privát assemblyt készítünk. A közhasznú objektumokat (fájltömörítő) írhatjuk nyilvános assembly kóddal is. Tegyük fel, hogy egy privát assemblyt akarunk készíteni. A .Net rendszer modellje ennél egyszerűbb nem is lehet. Lefordítunk egy egyszerű DLLassemblyt, majd az azt felhasználó ügyfélassemblly könyvtárába másoljuk. Nincs szükség a bejegyzésre a rendeszleíró adatbázisban. A kód egyetlen része sem változik meg a mi beavatkozásunk nélkül, így nem találhatjuk szembe magunkat a jól ismert helyzettel : megosztva használt DLL-t valaki más változatra cseréli, az általunk használt alkalmazás pedig lefagy. Ezzel a megközelítéssel az a szembetűnő probléma, hogy túlzottan sok assemyblynk lesz. Ennek a problémának a megoldására vezették be már a Windows 1.0 verziójában a DLL-eket. Ha például minden alkalmazás használ text boxot és mindegyiknél külön szükség van az azt megvalósító DLL egy példányára, az assemblyk gombamód elszaporodnak a számítógépen. Ezért szükség van sajnos arra, hogy bizonyos assemblyket megosszunk a számítógépen alkalmazások között. A .Net keretrendszer a globális assembly-gyorsító tárba KAC-ba helyezi az osztott használatú assemblyket. Ez a számítógép egyik könyvtára, ahol minden ilyen assembly megtalálható. A legtöbb felhasználó által használt Assembly Cache Viewer-t használja ezeknek az assemblyk megjelenítésére és módosítására. Ez a Windows felhasználói felületének kiterjesztése, amely a .NET SDK-val együtt települ. Automatikusan beépül a Windows Explorerbe (az intézőbe). Fájlok osztott használata esetén mindig probléma a nevek ütközése. A .Net-beli osztott assemblyk mindegyike bekerül a GAC-ba, itt pedig szükség van arra, hogy minden egyes külön kódfájl egyedi nevet kapjon. Erre való a strong name vagy a shared name. Az erős név a nyilvános kulcsú titkosítás révén garantálja a rendszerben szereplő összes assembly nevének egyediségét. Az osztott assembly mani fesztje nyilvános/privát kulcspár nyilvános kulcsát tartalmazza. A fájlnév és a nyilvános kulcs kivonata együtt tartalmazza az erős nevet. Az osztott assembly aláirásánál használt nyilvános kulcsú titkosítási módszer előnye, hogy az assemblyfájl sértetlenségét is lehet vele ellenőrizni. Az assemblygenerátor a manifesztben felsorolt fájlok tartalmából ellenőrzőösszeget, hash-értéket képez, majd azt a privát kulccsal titkosítja, és a titkosított hash értékét a manifesztben tárolja. Amikor a programbetöltő a GACból előveszi az assemblyt, ugyanazzal a módszerrel ő is ellenőrző összeget
képez az assembly fájlokból, majd a nyilvános kulccsal megfejti a manifesztben tárolt hash értékét, és a kettőt összehasonlítja. Ha egyeznek, a programbetöltő biztos lehet benne, hogy az assemblyfájlokhoz nem nyúltak.
1.3.3 Az assemblyk és a verziókezelés Nyilvánosságra hozott kódok megváltoztatása régóta problémát jelent, melyet gyakran DLL problémának neveznek. Ha új verziójú DLL-t telepítünk a régi helyett, amelyet az ügyfél még használ, két oldalról kaphatjuk a pofont. A régi alkalmazások új kóddal gyakran nem hajlandók működni. Hiába próbáljuk lefelé kompatibilissé tenni a kódot, sohasem lehetünk teljesen meggyőződve a kompatibilitásról. Másik probléma, ha egy telepi tett alkalmazás felülírja az új DLL-t egy régivel és az új DLL-t használó alkalmazás nem fog futni. Ez gyakran megtörténik, hiszen amikor a telepítőprogram kiírja, hogy a célfájl már létezik, és újabb a forrásnál és megkérdezi, hogy felülírja-e, a felhasználók 90%a igennel válaszol. Ezek a verzióhibák költségesek : miattuk csökken a termelékenység és nő a hibaelhárításra fordított idő. A Windows a verziókezelés problémáját áthárította a fejlesztőkre. A .Net előtt sohasem lehetett szabványosított formában meghatározni a programok kívánatos viselkedését a verziókezeléssel kapcsolatban. Az assemblyk verzióinformációja a manifesztben található. Ez az információ a kompatibilitási verziót jelenti, amely 4 számból áll. Ezek segítségével a CLR programbetöltő biztosítja az ügyfél által megkívánt verziókezelési működést. A kompatibilitási verziószám fő és másodlagos verziószámból, build-számból és revíziószámból áll. Az assemblyt létrehozó fejlesztőeszközök a verziószámot a manifesztben közlik. A manifeszt megjelenitett verzióinformációt is tartalmazhat, amely bárki által elolvasható karakterlánc. A megjelenített verzióinformációval a CLR nem törődik – ennek célja a felhasználó tájékoztatása. Az ügyfélassembly lefordításakor az assembly tartalmazza a felhasznált külső assemblyk nevét. Az ügyfél futtatásakor a CLR megpróbálja megkeresni az ügyfél által igényelt verziót. Alapértelmezett verizókezelési működés során pontosan arra a verzióra van szükség, amelyet az ügyfél fordításakor használtak, különben meghiúsul az assembly betöltése. Minden ügyfélassembly azt a verziót használja, amelynek segítségével megírták és tesztelték. Néha azonban nem erre a verziókezelésre van szükségünk. Tegyük fel, hogy a kiszolgáló eredeti verziójában felfedezünk egy végzetes mellékhatást, teszem azt, biztonsági rést, és azonnal az új verziót akarjuk használni. Nincs szükség arra, hogy újra lefordítsuk az összes ügyfelet az új verzióval, mint a klasszikus DLL-ek esetében. Ehelyett egy konfigurációs fájl segítségével felülbírálhatjuk a rendszer alapértelmezett működését.
1.4
A .Net memóriakezelése
A modern alkalmazásokban a kellemetlen, fáradtságosan megtalálható hibák egyik legfőbb oka a rosszul alkalmazott kézi memóriakezelés. A C++ megkívánja, hogy a programozók manuálisan töröljék az objektumot, amit létrehoztak. Ez két fő problémához vezet. Az első : a programozók megfeledkeznek az általuk létrehozott objektumról, amikor már nem használják őket. Az otthagyott memóriablokkok végül elfoglalják a folyamathoz szükséges memória egészét. A második : a programozó manuálisan töröl egy objektumot, majd később tévedésből megpróbál ennek a memóriahelyéhez fordulni. A Visual Basic azonnal érzékelné az érvénytelen memóriaterületre való hivatkozást, de a C++ ezt többnyire nem teszi meg. A modern programozási nyelvekben, például a Visual Basicben, Javaban nincs ilyen típusú probléma, mert ezek rendelkeznek a „használd, majd felejtsd el” típusú automatikus memóriakezeléssel. A Visual Basic 6.0 számolja, hogy az egyes objektumokra hány helyről hivatkoznak, és ha a hivatkozási szám 0 lesz, akkor törli az objektumot és visszanyeri a memóriaterületet. A Microsoft az automatikus memóriakezelést a .NET CLR részévé tette, amely így bármelyik programnyelv számára hozzáférhető. A koncepció nagyon egyszerű, amint azt az 1.4.1-es ábra jelzi.
Ügyfél Public Sub foo
Felügyelt halom O b j. A
1.A p r o g r a m l étre h o z z a a z o b j e kt u m o t, a m e m ó r i a k e z e lő m e m ó r i át f o g l al a fel ü g y e lt h a l o m b a n , m a j d a p r o g r a m m e g k a p j a a z err e v o n at k o z ó h i v at k o z á st. Dim bar As New A
Rendszer szemétgyűjtő (GC)
End Sub
3.A G C p e ri o d i k u s a n m e g v i z s g á lj a, h o g y a z o b j e kt u m r a m u t at-e h i v at k o z á s, é s h a n e m a k k o r a ut o m ati k u s a n t örli.
2.A f ü g g v é n y v i s s z até r, a h i v at k o z á s m e g s z ű n i k, a fel ü g y e lt h a l o m b a n l e v ő o b j e kt u m r a n i n c s t ö b b h i v at k o z á s
1.4.1 ábra : Automatikus memóriakezelés, szemétgyűjtéssel A programozó létrehoz egy objektumot a new operátor segítségével, és megkapja a hivatkozást. A CLR lefoglalja ennek az objektumnak a memóriahelyét a felügyelt halmon (managed heap), amely része annak a memóriának, melyet a CLR fenntart a folyamat számára. A rendszerszál időről időre megvizsgálja a felügyelt halmon levő objektumokat, hogy lássa, melyikükre van még a programnak elintézendő hivatkozása. Az olyan objektumok, melyekre már nem mutat hivatkozás, szemétté válnak, és a rendszer törli őket a felügyelt halomról. A felügyelt halmon megmaradó objektumokat ezután összetömöríti, és a programban kijavítja a rájuk mutató hivatkozásokat, hogy azok az objektumok új helyére hivatkozzanak. Ez a művelet a szemétgyűjtés (garbage collection). A szemétgyűjtés megoldja a korábban említett kézi memóriakezelés problémáit, anélkül hogy bármilyen programkódot kellene írni. Nyilvánvaló, hogy a szemétgyűjtés futtatása több processzoridőt igényel, de ez az időbefektetés megéri a gyorsabb fejlesztés és kevesebb hibaejtés érdekében. A szemétgyűjtés automatikus, de kézzel is előhívhatjuk a system.GC.Collect metódus hívásával. Ezt a hívást a program meghatározott logikai pontjain adhatjuk ki. Az automatikus szemétgyűjtés nagyon jól fest eddig, de azért van benne egy kis hézag. Ki takarít ki, amikor a program megsemmisít egy objektumot ? A C++ alkalmazások általában objektumdestruktorral takarítanak, a Visual Basic osztályok is ugyanezt teszik a Class_Terminate metódusok révén. A destruktor jó hely a takarítókódnak, mert az ügyfél nem feledkezhet meg annak hívásáról, de hogyan lehet ezt megvalósítani az automatikus szemétgyűjtéssel együtt ? A C++ destruktorai által elvégzett fő takarítási feladat az volt, hogy töröljék azokat az objektumokat, amelyekre a megsemmisített objektumhivatkozások vonatkoztak, erről most a szemétgyűjtés gondoskodik. De időnként olyan takarítást is el kell végeznünk, amely nincs kapcsolatban a szemétgyűjtéssel felszabaduló helyi erőforrásokkal : ilyen például az adatbázis-kapcsolatok bontása, vagy a kijelentkezés egy távoli rendszerből.
A CLR-beli szemétgyűjtés lehetővé teszi a véglegesítő (finalizer) futtatását. Ez olyan metódus, amelyet a rendszer hív meg, amikor a szemétgyűjtéssel készül eltakarítani az objektumot. Ez valamelyest analóg a C+ + osztálydestruktorával és a Visual Basic Class_Terminate metódusaival. Azonban a véglegesítő jelentősen eltér e két metódustól. Amikor egy objektum a szemétgyűjtés áldozatává válik, a szemétgyűjtést végrehajtó rendszerszál észleli, hogy az objektumban meg van valósítva a Finalize metódus. Ekkor meghívja azt, s így végrehajtja a takarítókódot. A véglegesítő használatának ugyanakkor vannak hátrányai is. Nyilvánvalóan igényel processzoridőt, ezért nem szabad használni, ha nincs takarítanivaló. Ugyanakkor nem ismert a használaton kívüli objektumok véglegesítőinek meghívási sorrendje sem. A véglegesítők nagyon jók, ha nem törődünk azzal, hogy a takarításra mikor kerül sor, ha az „ígérem, mire szükséged lesz rá meglesz” nekünk megfelel. Sokszor ennek is elégnek kell lennie. Mi történik azonban ha mégsem ? Ilyenkor mi azonnal szét akarjuk kapni az objektumot és felszabadítani az általa elfoglalt költséges erőforrásokat. Kikényszeríthetünk ez azonnali szemétgyűjtést, ahogyan azt korábban említésre került. A determinisztikus véglegesítés (deterministic finalization) módszer ezt nagyon hatékonyan végzi. A determinisztikus véglegesítést támogató objektumokban meg kell valósítani egy IDisposable nevű interfészt, amely egyetlen, Dispose nevű metódust tartalmaz. Ebben a metódusban helyezhetjük el azt a programkódot, amellyel felszabadítjuk az erőforrásokat. Az ügyfél meghívja ezt a metódust, ha azt akarja, hogy most azonnal szabadítsa fel az erőforrásokat.
1.4.1 Együttműködés a COM-mal Minden új szoftverplatform kereskedelmi sikere alapvetően függ attól, hogy milyen jól működik együtt a már meglévőkkel, miközben új utakat nyit a fejlesztés, vagy alkalmazások írása előtt. A Windows 3.0 például nemcsak lehetővé tette a DOS alkalmazások futását, hanem azok többfeladatos működését is megoldotta – jobban, mint előtte bármilyen termék -, ugyanakkor pedig teret adott a DOS alkalmazásoknál jobb Windows alkalmazások írásának. A Windows alkalmazások közötti kommunikáció 1993 óta a COM-ra épül. Alapjában véve minden Windows programkód nyakig benne van a COM-ban. A .Net keretrendszernek támogatnia kell a COM-ot, hogy üzleti szempontból legyen esélye. Ezt meg is teszi, akár mint olyan .Net ügyfél, amely COM kiszolgálót használ, és fordítva. Mivel valószínűbb, hogy az új .Net programkódnak kell a már meglévő COM programkóddal együttműködnie, ezt az esetet vizsgáljuk.
1.4.2 COM objektumok használata .Net-ből A .Net ügyfelek A COM kiszolgálót a futásidőben hívható burkoló (RCW, runtime callable wrapper) segítségével érik el, amint azt az 1.4.2 ábra is mutatja.
Futásidőben hivható burkoló
.Net ügyfél
.Net ügyfél
1.4.2 ábra : A .Net ügyfél és a COM objektum interakciója a futásidőben hívható burkolón keresztül A .Net ügyfél fejlesztője kétféleképpen hozhatja létre a RCW-t. Ha a Visual Studio.Net-et használjuk, egyszerűen csak rá kell kattintanunk a jobb egérgombbal a projekt References részére és az úszómenüből az Add reference parancsot kell választanunk. Ekkor megjelenik egy párbeszédablak, amelyben a rendszer összes regisztrált COM objektuma megjelenik. Elég kiválasztani azt a COM objektumot, amelyikhez létre akarjuk hozni az RCW-t : a Visual Studio.Net már adja is. Az algoritmus, amely a típuskönyvtárat olvassa és az RCW kódot generálja, a System.Runtime.InteropServices.TypeLibConverter nevű futásidejű osztályban található. Miután létrehoztuk az RCW-t, elképzelhető, hogy a névterét importálnunk kell az ügyfélprogramba (imports utasításokkal), hogy az objektumokkal a rövid névre hivatkozhassunk. Az RCW objektumot is a new operátorral hozzuk létre. Amikor létrejött, az RCW belülről meghívja a CoCreateInstance nevű függvényt, létrehozva a COM objektumot, amelyet beburkol. A .Net ügyfélprogram ezután úgy hívja meg a metódusokat az RCW-ben, mintha .Net objektum lenne. Az RCW az egyes hívásokat automatikusan átalakítja a COM hívási szabályoknak megfelelően és továbbítja az objektumhoz. A COM objektumtól érkező eredményt az RCW mielőtt visszaküldené az ügyfélnek, .Net típusokká konvertálja.
1.4.3 Tranzakciók a .Net-ben A tranzakciókra külön figyelmet kell fordítani az elosztott rendszerekben levő adatok integritásának megőrzéséhez. Tegyük fel, hogy hálózati díjbeszedő alkalmazást írunk! A telefonszámla befizetéséhez a folyószámlánkat valamilyen adatbázisban meg kell terhelni az összeggel, és ezt a telefontársaság számláján jóvá is kell írni, feltehetőleg egy másik adatbázisban, és valószínűleg egy másik számítógépen. Ha a mi számlánkat sikerült megterhelni, de nem történt meg a jóváírás, akkor a terhelést is törölni kell, különben a pénz elvész, és a rendszerben megsérül az adatok integritása. Biztosi tani kell, hogy legyen vagy mindkét művelet sikeres, vagy egyik sem. A két művelet tranzakciójaként való végrehajtása pontosan ezt teszi. Ha mindkét művelet sikeres, a rendszernek rögzítenie kell a tranzakciót, ekkor az új számlaegyenlegek az adatbázisba kerülnek. Ha viszont a művelet sikertelen, a tranzakció félbeszakad, és a számlaegyenlegek visszaállnak eredeti értékükre. A Microsoft Transaction Server és a COM+ is rendelkezik olyan automatikus szolgáltatással, amely megkönnyíti a programozók számára az olyan objektumok írását, amelyek tranzakcióban vesznek részt. A programozó manuálisan megjelöli azokat az objektumokat, amelyek tranzakciót igényelnek. Az objektum adatbázis módosításhoz COM+-beli erőforrás kezelőket használ, amelyek támogatják a COM+ tranzakciókezelést. Az objektum ez után jelzi, hogy elégedett-e az eredménnyel. Ha a tranzakcióban részt vevő minden objektum elégedett, a COM+ rögzíti a tranzakciót és értesíti az erőforrás kezelőket, hogy elmenthetik a módosításokat. A natív .Net objektumok is részt vehetnek tranzakciókban. A Microsoft jelenlegi tranzakciófeldolgozó rendszere a COM-ra épül, a .Net objektumok a COM-mal való együttműködés képességét használják ki. Ezzel az 1.4.2 fejezet foglalkozik. A .Net objektumokat COM kiszolgálóként kell bejegyezni. Ezután a COM+ Explorer program segítségével telepíteni kell a komponenst egy COM+ alkalmazásban.
1.4.4 Struktúrált kivitelezés Minden program találkozik hibával futás közben. A program megpróbál valamit tenni és a művelet valamilyen okból nem sikerül. Hogyan tudja megállapítani a program, hogy az adott művelete sikeres volt-e vagy sem? Hogyan írhatunk programot, amely ezt az utóbbi esetet kezeli ? A sikertelenül járó függvényekben alkalmazott klasszikus megközelítés az, hogy a függvény a sikertelenség jelzésére speciális értéket küld vissza, mondjuk a Nothing-ot. Ehhez külön kódot kell írni a függvény visszatérési értékének ellenőrzésére. A CreateWindow például a hiba jelzésére 0 értéket, a CreateFile a -1 értéket adja vissza.
Az egyes programnyelvek futási hiba kezelési eljárásai : • Visual Basic – On Error Go To • C++ és Java – structures exception handling (SEH) A .Net-beli CLR a C++ vagy Java nyelvekéhez hasonló struktúrált kivitelezést tesz lehetővé. Ez az architektúra megoldást ad azoknak a problémáknak a nagy részére, amelyek eddig kijátszották a hibakezelést. A hibát jelző függvény a hibát leíró információt egy .Net objektumban helyezi el, így az tetszőleges mennyiségű információt tartalmazhat. Mivel az infrastruktúra a CLR integráns része, már minimális programozással kihasználható.
1.4.5 A hozzáférés szabályozása A PC korszak hajnalán minden vásárló boltban vette meg a szoftvereket és frissítéseket. Ha egy szoftvercég által támogatott boltban vásároltunk, biztosak lehettünk benne, hogy a megvásárolt szoftvert tényleg az adott cég adta ki és nem tartalmazott ártalmas vírust. Sőt, gyakran zárjeggyel láttál el a dobozt, így a vásárló még nyugodtabb lehetett, hogy Ő előtte kizárólag a szoftvert kiadó cég munkatársai nyúltak a dobozba. Ez a biztonságérzet mára már eltűnt, hisz nem boltban vesszük szoftvereink nagy részét. A szélessávú internet kapcsolatok elterjedésével sokkal kézenfekvőbbé vált a webes szoftvervásárlás, ami a szoftverfejlesztőknek és a vásárlóknak is kedvező egyaránt. A fejlesztők sok pénzt és energiát takarítanak ezzel meg, a vevőknek pedig a kényelem és az olcsóbb árak jelentik az előnyt. A webről letöltött programkódban azonban nemcsak az általunk kívánt alkalmazás lehet. Mi történik, ha valaki egy szoftvercsomag keretein belül akarna a számítógépünkre egy rombolásra alkalmas vírust? Úgy tűnik nem telik el hónap, hogy a CNN-en egy kontinens méretű vírusra ne hívják fel figyelmünket. A webes szoftverterjesztés a vállalkozók szempontjából maga a paradicsom, de ez a környezet újabb biztonsági kérdéseket vet fel. Honnan tudhatjuk, hogy megbízhatunk egy ismeretlen cég szoftverében? A Microsoft a webes programkódok biztonságossá tételére először az Authenticode-rendszerrel próbálkozott még 1996-ban, az ActiveX SDK-ban. Az Authenticode segítségével a fejlesztők digitális aláírást csatolhattak a letöltendő vezérlőelemekhez, így a vásárló valamennyire megnyugodhatott, hogy a vezérlőelemet tényleg az adta ki, akinek mondja magát, és hogy az aláírás óta senki sem nyúlt hozzá. Az Authenticode egész jól garantálta, hogy az Internet Explorer frissítését tényleg a Microsoft adta ki. A Microsoft megpróbálta biztosi tani webes környezetben a bolti vásárlás biztonságosságát, de ez a modern világban kevésnek bizonyult. A digitális bizonyítványok kiadását megelőző felületes vizsgálat nem garantálja a bizonyítványt használó cég jó szándékát.
Az Authenticode jelszava: „mindent vagy semmit” volt. Aránylag megbízhatóan mondta, hogy kitől származik a kód, de ezen felül csak arról dönthettünk, hogy telepítjük-e vagy sem. Ha a kód már a rendszerben volt, sehogy sem lehetett megfékezni. Az Authenticode ugyanis nem biztonsági, hanem csupán felelősségi rendszer. Ha a kód károkat okoz a rendszerünkben, tudjuk kit kell elővenni. Jó lenne tehát, ha minden egyes kódrészlet lehetőségeit külön korlátozhatnánk bizalmunk arányában. Ismerőseink az irántuk táplált bizalom alapján férhetnek hozzá vagyontárgyainkhoz : egy jóbarát kölcsönkérheti a régi autót, egy rokon megkaphatja a nyaralónk kulcsát, a szomszéd pedig használhatja a kerti slagot. Az volna az igazi, ha az operációs rendszer ugyanilyen megkülönböztetéseket alkalmazna. Az operációs rendszer például engedélyezhetné, hogy az internetről letöltött vezérlőelem hozzáférhessen felhasználói felületünkhöz, ugyanakkor megtilthatná neki a merevlemezen levő fájlok elérését. A Win32 nem tartalmaz ilyen funkciót, mivel nem erre a célra készült, viszont a CLR egyik alapgondolata pedig pont ez a probléma. A .Net CLR lehetővé teszi a kódhozzáférés-szabályozást. Ez azt jelenti, hogy a rendszergazda előnyben részesíthet bizonyos felügyelt kódot tartalmazó assembly-t, attól függően, hogy mennyire bízik meg benne. Amikor a felügyelt kód CLR hívás segítségével védett erőforrást próbál elérni, pl. megnyitni egy fájlt, a CLR ellenőrzi, hogy erre megvan-e a rendszergazdától kapott engedélye. A CLR az ellenőrzés során végigmegy a hívási vermen : így a bizalmi körön kívül eső felső szintű assembly sem képes kikerülni a biztonsági rendszert azzal, hogy az alacsonyabb szinten nagyobb bizalmat élvező assembly-t hív meg. (Amikor a bébiszitter elmegy a gyerekért a boltba, nem volna-e jó, ha a tanár leellenőrizné, hogy a bébiszittert valóban mi küldtük-e ?) Igaz ez a folyamat lassítja az erőforrások elérését. A rendszergazda biztonsági házirendet hozhat létre (security policy). A Windows Vista-ban ilyet tehetünk a User Account Controlban. Ebben szabályok sorát kell létrehozni, megszabva, hogy melyik assembly milyen műveletre kap engedélyt tőlünk. Az engedélyezéseknek három formája ismert : vállalat, számítógép és felhasználó. Az alacsonyabb szintű beállítás tovább szigoríthatja a magasabb szintű beállításokat, ez fordítva viszont nem igaz! Lehetséges például, hogy a számítógépszintű engedély miatt az assembly megnyithat egy fájlt, a felhasználói szintű engedély pedig megtagadja ezt a műveletet az assemblytől. Ez a korlátozás fordított sorrendben nem érvényesíthető. A rendszergazda a merevlemezen tárolt XML alapú konfigurációs fájlok szerkesztésével állítja be a biztonsági házirendet. Az assemblykhez úgynevezett engedélykészletet (permission set) is rendelhetünk, amelyek egységként, együtt kiadható és megvonható privilégiumlisták. A korszerű alapértelmezett biztonsági
beállítások többféle engedélykészletet is tartalmaznak, amikből kedvünkre válogathatunk. A fentiekből létrehozhatunk személyünkre szabott engedélykészletet is. Az engedély a jog az adott művelet elvégzésére, például a felhasználó által párbeszéddobozban kiválasztott fájl megnyitására, esetleg olyan megszorítással, hogy csak olvasásra lehet megnyitni, írásra nem. Most, hogy tudjuk milyen engedélyeket adhat ki a rendszergazda, nézzük meg az engedélyek kiosztásának mikéntjét ! A legtöbb rendszergazda, aki felhasználói jogokat felügyel, felhasználócsoportokat hoz létre (munkások, irodai dolgozók..). A csoport minden tagja egyforma jogokkal rendelkezik, a csoportokat bármikor módosíthatja. Ehhez hasonlóan a programkód jogait felügyelő rendszergazdák többsége valószínűleg assemblycsoportokat, úgynevezett kód-csoportokat hoznak létre, és ezekhez rendel különböző engedélykészleteket. Amikor egy kódot töltünk le a webről, nem lehet újra és újra döntést hozni az új assembly hozzánkférhetőségéről, ezért a programkód jogait felügyelő rendszergazda szabályokat, ún. tagsági feltételeket (membership condition) hoz létre. Ezek a szabályok határozzák meg az assemblyk kódcsoportokhoz való hozzárendelésének módját. A tagsági feltétel figyelembe veszi az assembly erős nevét és az aláírás nyilvános kulcsát is. Amikor a CLR betölt egy assemblyt, a tagsági feltételek alapján kitalálja, hogy melyik kódcsoporthoz tartozik és kódcsoportnak megfelelő engedélyezési készletet juttatja érvényre.
2.
Az ASP.NET
2.1 A probléma háttere Kezdetben a web csak szövegeket és képeket tartalmazó statikus oldalak megjelenítésére szolgált. A kiszolgálók programozása viszonylag egyszerű volt, fogadd az állományt azonosító URL-t hívd elő az állományt a kiszolgáló lemezéről, és írd az ügyfélre. Ez az egyszerű architektúra rengeteg mindenre jó. Ilyet alkalmaznak például egy mozi honlapjának a kivitelezésére (egyszerű megoldásként), ahol az oldal lekérése után megnézhetjük, hogy melyik filmet mikor vetítenek. Böngésző 1 . A f el h a s z n á l ó b e irja a k ér é st a b ö n g é s ző b e
2. A bongésző elküldi a kérést a kiszolgálónak
4. A b ö n g é s z ő m e g f or m á z z a é s m e g j e l e n iti a z o l d a lt a z ü g y f é l n é l.
Kiszolgáló 3. A k i s z o l g á l ó m e g k er e s i a k ért o l d a lt, é s v i s s za k ül di az ü g yfélnek.
2. o l d a l
n. ol dal o l dal
1.oldal
2.1.1 ábra : Statikus weboldalakat megjelenítő kiszolgáló Node felmerül a kérdés, hogy ha egy moziműsort megnézhetek az interneten, akkor miért ne nézhetném meg a bankszámlám egyenlegét is ? A bank nem tud minden nap az összes számla összes lehetséges nézetéhez külön weboldalt készíteni, ez túl sok erőforrást igényelne. Ehelyett a felhasználónak adatokat kell bevinnie, pl. számlaszámát, a bank számítógépe pedig egy HTML oldalt készít, amelyen az egyenleg látható. A folyamatot a 2.1.2 ábra mutatja be.
2. A bongésző elküldi a kérést a kiszolgálónak Böngésző 1 . A f el h a s z n á l ó b e irj a a k ér é st a b ö n g é s ző b e : 1 2 3 4 6 s z á m ú b a n k s zá m la f or gal m a 4. A b ö n g é s z ő m e g f o r m á z z a é s m e g j e l e n iti a z o l d a lt a z ü g y f é l n é l.
Kiszolgáló 3. A k i s z o l g á l ó h o z z áf ér a s z á m l a i n f or m á c i ó h o z , é s l étre h o z z a a k ért a d at o k at tartal m a z ó o l d a lt.
2.1.2 ábra : Webkiszolgáló, amely a felhasználói bevitel alapján dinamikusan generál weblapokat. Ez a dinamikus generálás sok problémát vet azonban fel. • a programozott eljárást társítani kell az oldalkéréshez • a kiszolgáló programozott eljárást hajt végre, amitől elvárjuk a gyorsaságot a termelési környezetben • a webkiszolgálónak lehetővé kell tennie a felhasználói bevitelt a kiszolgálóoldali program számára, és a programozott eljárás kimenetét vissza kell csatolnia a felhasználóhoz. • mivel adatain egy része bizalmas, a webkiszolgálónak meg kell bizonyosodnia arról, hogy a felhasználó az, akinek mondja magát, valamint az adatainkhoz kizárólag mi férhessünk hozzá. • végül a kiszolgálónak szüksége van olyan mechanizmusra, amely segítségével kezelni tudja a felhasználói munkameneteket.
Összefoglalva : A webkiszolgálónak olyan futtatási környezetre van szüksége, amely előregyártott megoldásokat biztosít az általános kiszolgálóoldali programozási problémákra. Fontos, hogy könnyen programozható legyen, emellett az alkalmazások felügyeletének és telepítésének is egyszerűnek kell lennie.
2.2 A megoldás áttekintése A Microsoft 1997 őszén az IIS-en (Internet Information Server) belül kiadott egy viszonylag egyszerű webes futtatókörnyezetet, az ASP-t (Active Server Pages). A felhasználó által kért oldalakat az IIS szolgáltatta. Az ASP lehetővé tette a programozók számára, hogy olyan programozott eljárásokat írjanak, amelyek dinamikusan építik fel az IIS által szolgáltatott, statikus HTML és parancsnyelvi programkód keverékéből álló oldalakat.
T h e ti m e i s : <% =ti m e %> o n <% =date %> 2.2.1 ábra : A programkód és a HTML keveréke az ASP-ben Ahogy a web használata egyre terjedt, és a felhasználói igények is egyre nőttek, úgy követeltek a webprogramozók is egyre több intelligenciát a webes futtatókörnyezettől. A két legfontosabb szempont az egyszerű programozás és a gyors futás. Az ASP.NET mindkét területen előrelépést jelentett. AZ ASP-hez képet a belsejét teljesen újraírták, hogy ki tudja használni a .Net keretrendszer minden előnyét. Az ASP.NET a mögöttes kódok (code-behind) nevezett szolgáltatásával elkülöniti egymástól a HTML kimenetet és a programozott eljárást. A HTML és a kód összekeverése helyett, a kódot külön oldalra irja és az ASP oldal erre az oldalra hivatkozik. Az ASP.NET támogatja a Web Forms, és a webűrlapok használatát. A Web Forms olyan weboldal-architektúra, amely a weboldal programozását a Windows alkalmazás űrlapjainak programozásához teszi hasonlóvá. Az oldalra vezérlőelemeket vihetünk fel, ezekhez pedig eseménykezelőket írunk. Az eredeti ASP kevésbé támogatta a biztonsági programozást, ellenben az ASP.NET, ahol ez sokkal jobban támogatott. Minden Windows felhasználót automatikusan hitelesíthetünk, (ellenőrizhetjük, hogy valóban azok-e akiknek mondják magukat) a Windows hitelesítési eljárásával.
Az ASP.NET több új és hasznos futtatási szolgáltatást is nyújt. Az eredeti ASPben a programok meglehetősen lassan futottak, mert a rendszer csak futásidőben értelmezte az oldalak parancsnyelvi programkódját. Az ASP.NET automatikusan lefordítja az oldalakhoz tartozó kódot, amikor az oldalt telepítjük, vagy amikor a felhasználó először fordul hozzá. Ez teszi gyorsabbá a futást. Mivel az ASP.NET a .Net keretrendszer JIT fordítóját alkalmazza, nem kell megállítani a kiszolgálót, ha ki kell cserélni egy komponenst vagy egy oldalt. Az ASP.NET emellett a programok újraindítását is támogatja. Nem hagyja, hogy egy folyamat a végtelenségig fusson : beállíthatjuk, hogy az ASP.NET meghatározott idő vagy találatszám elérésé után automatikusan leállítsa és újraindítsa a kiszolgálófolyamatot. Így megelőzhetjük a memóriaszivárgást, amely több alkalmazás programkódjában probléma. Az ASP.NET emellett könnyen felügyelhető, mert minden beállítást emberi szemmel is olvasható állományokban tárol, az ASP könyvtárhierarchián belül.
2.3 A Webes vezérlőelemek A webes vezérlőelemek ugyanarra a filozófiára épülnek, mint a Windowsos felhasználói felület vezérlőelemei. Ez az architektúra Bill Gatest a világ leggazdagabb emberévé tette. A Windows 3.0-ban nem volt szabványos fájlmegnyitó párbeszéddoboz, minden alkalmazáshoz meg kellett írni külön. Ez a Windows 3.1-ben már az operációs rendszer része volt, ami sokat könnyítette a programozók életén. A webes vezérlőelem a szó ASP.NET értelmében bármilyen felhasználói felülethez kapcsolódó programlogika, amely képes a) megvilágítani egy standard programozási modellt egy fejlesztői környezetben, például Visual Studio.NET-ben és b) a megjelenést a HTML-ben megformázni, hogy egy standardböngésző bemutathassa – többé kevésbé úgy, mint ahogy a Windows-vezérlőelemek a Windows GDI-függvényhívások formájában jelennek meg. 2.3.1 ábra : WebForms kiszolgálóoldali vezérlőelemeinek alapkészlete Funkció Vezérlőelem Leírás Olyan szöveg megjelenítése, Olvasható Label – Címke amelyet a felhasználó nem szövegmegjelenítés Szöveg szerkesztése
TextBox – Szövegmező
Választás listáról
DropDownList –
tud közvetlenül szerkeszteni Tervezési időben megirt szöveg megjelenítése, amelyet a felhasználó futásidőben és programozott módon szerkeszthet. Lehetővé teszi, hogy a
felhasználó listából válasszon vagy szöveget írjon be Választási lehetőségek ListBox – Listamező listáját jeleníti meg. A listán egyszerre több elem is kiválasztható Kép megjelenítése Image – Kép Adrotator – Képsorozat Képek sorozatának megjelenítése CheckBox – Jelölőnézet Jelölőnézet megjelenítése, amely segítségével a felhasználó be és kikapcsolhat egy paramétert Rádiógomb megjelenítése, RadioButton – amely ki és bekapcsolt Rádiógomb állapotban lehet Lehetővé teszi a Calendar – Naptár felhasználónak, hogy dátumot válasszon ImageButton – Képgomb Button vezérlőelemhez hasonlít, de a szöveg helyett képet tartalmaz Webes hivatkozások Hyperlink – létrehozása Hiperhivatkozás
Legördülőlista
Grafika megjelenítése Értékek beállítása
Dátum megadása
Navigáció Táblázatvezérlő elemek
Csoportosítás
Listavezérlő elemek
Table – Táblázat TableCell – Táblázatcella TableRow – Táblázatsor CheckBoxList – Jelölőnézetlista RadioButtonList – Rádiógomb lista Repeater – Ismétlő
DataList – Adatlista
Táblázat létrehozása Új cella létrehozása táblázat egyik sorában Új sor létrehozása a táblázatban Jelölőnézetek csoportba szervezése Rádiógombok csoportjának létrehozása. A csoporton belül csak egy gombot lehet kiválasztani Adathalmaz tartalmának megjelenítése meghatározott HTML-elemek és vezérlőelemek segítségével. A formázóelemeket az adathalmaz minden rekordjára megismétli A Repeater vezérlőelemhez hasonlít, de több formázási és tördelési beállítást tesz lehetővé, pl : adatsorok táblázatos megjelenítését. A
DataGrid – Adatrács
DataList vezérlőelemmel meghatározhatjuk a szövegszerkesztés viselkedését is Információk adatvezérelt megjelenítése táblázatos formában, oszlopokkal.
A webes vezérlőelemek csomagjában (listamező, szövegmező, rádiógomb..) levő beviteli vezérlőelemek nagyszerű tulajdonsága, hogy automatikusan megjegyzik az utolsó állapotukat, amíg az őket tartalmazó oldal oda-vissza megjárja az ügyfél és a kiszolgáló közt. A Microsoft ezt a szolgáltatást adat-visszaküldésnek vagy visszaküldendő adatnak (postback data) nevezi. A webes vezérlőelemek csomagjában levő megjelenítési vezérlőelemek (címke, adatlista, adatrács és az ismétlő) szintén megőrzik tulajdonságukat. Ennek a szolgáltatásnak a neve nézetállapot (view state). Ugyan nem a felhasználó állítja be ezen vezérlőelemek értékét, azok megjegyzik az előző üzenetváltás során beállított állapotot. Az .ASPX –oldalakat kezelő környezet minden automatikusan elhelyez egy rejtett beviteli vezérlőelemet (viewstate). A webes vezérlőelemek automatikusan beviszik az állapotukat ebbe a rejtett vezérlőelembe amikor az oldal megsemmisül és kiolvassák azt, amikorra z oldal legközelebb létrejön. A Webes vezérlőelemek meg tudják határozni a felhasználó böngészőjének típusát. Így, ha szükséges a vezérlőelemek a különböző böngészők tulajdonságait kihasználva formázzák meg a HTML-t.
2.4 Állapotkezelés az ASP.NET-ben Alapértelmezés szerint a weboldalkérések függetlenek egymástól. Ha a kiszolgálótól a www.mogi.bme.hu oldalt kérem, annak a tartalma nem is tud arról, hogy megnéztem-e előtte a www.get.bme.hu oldalt is. Ez a mechanizmus remekül működik egyszerű olvasási kérések esetén. Ahogy a webes kommunikáció egyre bonyolultabbá bálik, a fenti működési mód egyre kevésbé felel meg a felhasználó elvárásainak. Amit csináltam az A oldalon, igenis befolyásolhatja a B oldal tartalmát. Például repülőjegy foglaláskor : elvárhatjuk, hogy a légitársaság webhelye automatikusan emlékezzen a kiválasztott induló járatra, amíg kiválasztom a visszatérő járatot is és, hogy megjegyezze mindkét járat számát, amíg
megveszem a repülőjegyet. A weboldalnak el kell különítenie az én járat adataimat másokétól is, hogy ne keveredjenek azok össze. Ezt az eljárást munkamenet – állapotok kezelésének (session state management) nevezzük. A Az ügyfél böngészője 1 . A z ü g y f é l k éri a z el s ő o l d a lt
M u n k a m e n et a z o n o s it ó s üti
Kiszolgáló 2. A k i s z o l g á l ó m e g k a p j a a k ér é st, é s l étre h o z z a a S e s s i o n o b j e kt u m o t. A z a d at o k at s üti k f or m á j á b a n a z ü g y f é l n é l tár o l j a. 3. A p r o g r a m o z ó a S e s s i o n o b j e kt u m b a n k e z e l i a z a d at o k at. 5 . A k i s z o l g á l ó tra n s z p ar e n s m ó d o n e lő hi v j a a s üti által a z o n o s it ott S e s s i o n o b j e kt u m ot.
4. A z ü g y f é l k ér i a m á s o d i k o l d a lt, e n n e k s o r á n v i s s z a k ü l d i a s ütit.
6. A p r o g r a m o z ó k o l v a s s a a z a d at o k at a S e s s i o n o b j e kt u m b ó l , a m e l y, a m e g f e l e lő fel h a s z n á l ó a d atait tartal m a z z a.
7 . A z el s ő o l d a l o n v é g z ett m ű v e l et ei al a p j á n a z ü g y f é l m e g k a p j a a m á s o d i k o l d a lt.
programozónak ennek kezeléséhez hatékony és könnyen programozható módszerre van szüksége.
2.4.1 ábra : A munkamenet állapotok kezelése Noha a munkamenet kezelési mechanizmust az eredeti ASP-ben könnyen lehetett használni, több probléma is felmerült, amely megakadályozta, hogy a mechanizmust nagy rendszerre is ki lehessen terjeszteni. Először is, ez a mechanizmus a futó munkafolyamatok memóriaterületén tárolta a munkamentek állapotát. Ugyanezek a munkafolyamatok futtatták az oldalakba ágyazott parancsnyelvi kódot és a programozó által egyedi objektumok kódját is. Egy rosszul megirt objektum miatt a folyamat könnyen összeomlott, ezzel pedig megszűnt minden felhasználó munkamenet állapota. Az ASP.NET megoldást kínál erre a problémára. A munkamenet állapotot külön folyamat tárolja, amely önálló rendszerszolgáltatásként működik, így a rosszul megirt, felhasználói programkód nem tudja tönkretenni a munkamenet állapotokat.
<ses s i o n S t ate m o d e=”i n p r o c ” state C o n n e cti o n S tri n g=”tc p i p=12 7. 0. 0. 1 : 4 2 4 2 4 ” s q l C o n n e n cti o n S tri n g=”data s o u r c e=12 7. 0. 0. 1 ; u s e r i d=sa; p a s s w o r d=” c o o k i e l e s s=”fal s e ” ti m e o ut=”2” /> 2.4.2 ábra : Munkamenetállapot kezelési bejegyzések a web.config fájlban
2.5 Biztonság az ASP.NET-ben A biztonság az elosztott programozás életfontosságú része. A hitelesítés és engedélyezés műveletei elengedhetetlenek egy modern rendszerben.
Hitelesítés (authentication) Az első biztonsággal kapcsolatos probléma : ki vagy te, és honnan tudjam, hogy tényleg az vagy, akinek mondod magad ? A felhasználó hitelesítése általában abban merül ki, hogy személyes adataival leellenőrzésre kerül. Ha a hitelesítési adatok elegendőek a kiszolgáló számára, akkor tudjuk, hogy a felhasználó kicsoda, és a belső logika segítségével meghatározhatjuk, hogy milyen műveletek elvégzésére jogosult. Azt a felhasználót, akit a rendszer nem hite lesit, névtelen felhasználónak (anonymus user) nevezzük. Alaposan meg kell gondolni, hogy a weboldalon hol legyen a hitelesítés. A webhelyet, úgy kell megtervezni, hogy a biztonságot igénylő szolgáltatások valóban biztonságosak legyenek, de ne legyen útjában a védelmet nem igénylő műveleteknek. Az ASP.NET hitelesítési eljárásai során nem biztosítják az ügyféltől a kiszolgálónak küldött adatok titkosítását. Ez a probléma nem az ASP.NET-ben, hanem a webes szállítási protokoll, a HTTP problémája. Nézzünk meg különböző hitelesítési eljárásokat !
1.
Windows hitelesítés Az ASP.NET támogatja a Windows hitelesítést, ami gyakorlatilag azt jelenti, hogy a hitelesítési folyamat a webkiszolgáló infrastruktúrához, az ISS-hez fordul, amelyen az ASP.NET is csücsül. Az IIS-ben előírhatjuk, hogy a felhasználó böngészőjében párbeszéddoboz jelenjen meg, ahol a felhasználóazonosítót és jelszót kell megadni. A hitelesítési adatoknak egyértelműen azonosítaniuk kell egy felhasználói fiókot, amely az IIS állomást is tartalmazó tartományban van nyilvántartva. A Windows hitelesítés jól működik a csak Windows-t használó intranetekben.
2.
Hitelesítés űrlappal vagy sütivel
Az ügyfél böngészője
Kiszolgáló
1 . A f el h a s z n á l ó űrla p o s h itel e s ité st al k a l m a z ó o l d a lt k ér
2. A z A S P. N E T é s z l e l i, h o g y v é d ett erő f orrá s h o z p r ó b á l n a k h o z z áf ér ni a b e l é p é s r e j o g o s it ó s üti n é l k ü l. Á t i r á n y itja a fel h a s z n á l ót a p r o g r a m o z ó által k é s z itett b e j e l e nt k e z é s i k é p er n y ő re
4. A z er e d eti o l d a l é s a s üti v i s s z a k ü l d é s e 5 . A t o v á b b i o l d a l k ér é s e k s o r á n a s üti m i n d i g e lj ut a k i s z o l g á l ó h o z
7 . A m u n k a m e n et v é g é n a z ü g y f é l e l d o b j a a s ütit, v a g y tár o lj a a zt, h o g y k é s ő b b n e k e l l j e n ú j ra b e j e l e nt k e z n i.
3. A p r o g r a m o z ó b e k ér i a fel h a s z n á l ó a z o n o s it ót é s a j el s z ót a b e j e l e nt k e z é s i k é p er n y ő n é s e l v é g z i a b e l s ő e l l e n ő r z é st. H a a z a d at o k m e g f e l el n e k, m e g h i v e g y re n d s z er f ü g g v é n yt, a m e l y e e lő állitja a s ütit, é s v i s s z a ir á n y itja a z ü g y f e l et a z er e d eti o l d a lr a. 6. A z A S P. N E T é s z l e l i a v é d ett erő f orrá s h o z v a l ó h o z z á f ér é st é s a s üti m e g l ét ét; k i s z o l g á l j a a k ér é st
3.
Passport alapú hitelesítés A Microsoft Passport célja, hogy univerzális, egy lépésből álló és biztonságos bejelentkezési eljárást nyújtson. Erősen hasonlít az előző részben ismertetett űrlapos hitelesítési mechanizmusra, azt kivéve, hogy a felhasználóazonosítókat és a jelszavakat a Microsoft által üzemeltetett Passport webkiszolgálók tárolják és ellenőrzik. A felhasználó ellátogat a Passport webhelyre és létrehoz egy igazolványt (passport), ez nem más, mint egy felhasználóazonosító és egy jelszó a Microsoft központi kiszolgálófarmján. Amikor a felhasználó olyan helyről kér oldalt, amely Passport hitelesítést használ, a webhely a kérésben a Passport sütit keresi. A folyamatot a következő ábra mutatja :
MICROSOFT PASSP OR T w e b f ar m
Hozzáférés –engedélyezés (authorization) Mihelyst a hitelesítési folyamat befejeződik, ismerjük a felhasználót, vagy tudjuk, hogy névtelen felhasználóval van dolgunk. Most azt kell eldöntenünk, hogy a felhasználó megnézheti-e az oldalt, amelyet szeretne. Ez a hozzáférés engedélyezése. Az ASP.NET jól támogatja az .ASPC oldalakhoz való hozzáférés szabályozását is. A hozzáférést az alkalmazás web.config fájljába írással korlátozhatjuk.
<den y u s e r s=” * ” /> 2.5.3 ábra : Engedélyezési bejegyzések a web.config fájlban Amikor a felhasználó kér egy oldalt, az ASP.NET a felsorolás sorrendjében kiértékeli a web.config fájlban leirt szabályokat, amíg nem talál egy olyan szabályt, amely megmondja, vajon engedélyezze vagy megtagadja-e a kért oldalhoz való hozzáférést a felhasználótól. Ha a folyamat mindent rendben talál, engedélyezi „Simba” és ”Doctors” felhasználóknak a kívánt műveletet.
Az ASP.NET lehetővé teszi, hogy a felhasználók mellett teljes felhasználócsoportok hozzáférését is szabályozzuk. A gyakorlatban a legtöbb
rendszer az egyedi felhasználók szintjén nemigen szabályozza a hozzáférést, a hozzáférés engedélyezés majdnem mindig a csoportszinten történik. Amikor Windows hitelesítést alkalmazunk, az ASP.NET a rendszergazda által létrehozott szabványos Windows csoportokat eleve szerepeknek tekinti. Az adott csoporthoz tartozó felhasználók automatikusan tagjai szerepnek. Ehhez nekünk semmit sem kell tennünk, a csoporttagságot a rendszer automatikusan felismeri. Viszont ha süti, vagy Passport alapú hitelesítést alkalmazzuk, a szerep meghatározása nehezebbé válik. Az ASP.NET nem tudja, hogyan tároljuk a felhasználói adatokat, és azt sem, hogy az alkalmazásban mi számit szerepnek. Így magunknak kell megírni a kódot, és azt hozzá kell kapcsolni a ASP.NET környezethez : az ASP.NET így visszakérdezhet, hogy a felhasználó tagja az adott szerepnek.
3. Webszolgálatások a .Net-ben 3.1 A webszolgáltatások létrehozásának okai A legfőbb ok a webszolgáltatások használata mellett az, hogy a TCP kommunikációt használják HTTP protokoll fölött, valamint a 80-as portot. Sok vállalat annak érdekében, hogy megóvja magát, tűzfalakkal szűri vagy blokkolja az internet forgalmat. Ebben a környezetben jellemzően a legtöbb (majdnem mindegyik) port zárva van a kimenő és bejövő forgalom ellen, és a tűzfal rendszergazdái nem is szeretnék ezeket megnyitni. Azonban a 80-as port mindig nyitva van, mivel a webböngészők ezt használják. A webszolgáltatás minden forgalmat a 80-as porton keresztül intéz, így nagyon vonzóvá téve a technológiát. M á s i k o k p e d i g a z, a m i a S O A P p r ot o k o l l erő s s é g e, h o g y n e m v o lta k e d d i g i g a z á n j ó fe l ü l ete k m á s g é p e k e n v a g y h á l ó z at o k o n t örté nő f ü g g v é n y h í v á s ra. A l e gt ö b b j ü k a d h o c j e ll e g ű v o lt, é s c s a k n é h á n y e m b e r tu dta a z E D I -t, a z R P C -t é s a h a s o n l ó A P I -k at k e z e l n i. A w e b s z o l g á ltatá s o k s o k k a l e g y s é g e s e b b k e r etre n d s z e rt tartal m a z n a k é s í g y s o k k a l e g y s z e rű b b ő ket h a s z n á l n i.
E g y h ar m a d i k o k , a m i a w e b s z o l g á ltatá s o k at h a s z n o s s á te s z i: la z a k a p c s o l at ot b i zt o s íta n a k a w e b s z o l g á ltatá s é s a z a zt h a s z n á l ó al k a l m a z á s k ö z ött. E z a tulaj d o n s á g l e h ető s é g et b i zt o s ít, h o g y b ár m e l y i k et m e g l e h e s s e n v á lt o ztat ni a m á s i k b e f o l y á s o l á s a n é l k ü l. E z a fl e x i b i litá s e g y r e f o nt o s a b b á v á l i k, m i v e l a s z o ft v e r e k ö n á l l ó k o m p o n e n s e k b ő l é p ü l n e k fel. A w e b s z o l g á ltatá s o k e lterj e d é s é r e j e l e ntő s h atá s s a l v a n/le s z a z ü z l eti s z e kt o r s z á m á r a n é l k ü l ö z h et etle n X M L ala p ú d o k u m e nt u m m e n e d z s m e nt re n d s z e r e k e lterj e d é s e. A s z e m a nti k u s w e b ( w e b 3 . 0 ) e g y i k j ö v ő b e m u t at ó c é l k itű zé s e, h o g y a d i g itáli s v i l á g re n d s z e r e i ( a d at b á z i s o k , p r o g r a m o k ) é s a z ü z l ete m b e r e k ( h u m a n o i d ) s z á m á r a i s e g y f o r m á n ( s z ö v e g e s e n ) értel m e z h ető s z a b v á n y o s a d at h o r d o z ó d o k u m e nt u m o k ( X M L ) re pr e z e ntálj á k a z ü z l eti i n f or m á c i ó k at. Ü z l et m e n et f o l yt o n o s s á g te k i nteté b e n re n d k í v ü l i j e l e ntő sé g g e l b í r, h o g y a v á l l al ati i n f or m á c i ó b á z i s m e n n y ir e p l atf or m - f ü g g etl e n, ill et v e, h o g y a d ott e s et b e n e g y d o k u m e nt u m h o z ( p l: s z er ző d é s, m e g r e n d e lő ) tart o z ó a d at o k é s ö s s z e f ü g g é s e k ( d i g itáli s l o g i k át ó l, k ó d o l á st ó l f ü g g etl e n ü l ) b e m u t at hat ó k é s b i z o n y ít h at ó k l e g y e n e k. A f ü g g etl e n d i g itáli s re n d s z e r e k k o l l a b o r atí v e g y ütt m ű k ö d é s ü k s o r á n s z a b v á n y o s e ljárá sr e n d b e n ( w e b s er v i c e ) a d j á k, v e s z i k é s értel m e z i k e z e n X M L d o k u m e nt u m o k at é s a s z á m u k r a e lő írt m ű v e l ete k et v é g r e h ajtjá k.
3.2 Felhasznált szabványok • •
•
•
•
Webszolgáltatás protokollkészlet – A webszolgáltatás megvalósítása során felhasznált szabványok és protokollok. XML – Minden kicserélendő adat XML címkékkel van formázva. Ezen kódolás SOAP vagy XML-RPC formában hajtható végre. Az ipari szabványok (biztonság, együttműködés…) a SOAP-ra alapulnak. Gyakori protokollok – az XML adat mozgatása az alkalmazások között az olyan gyakran alkalmazott protokollokkal történik, mint a HTTP, az FTP, az SMTP és az XMPP. WSDL – a webszolgáltatás nyilvános felülete a Webszolgáltatás leíró nyelvvel (Web Services Description Language, WSDL) van leírva. Ez egy XML alapú leírása a webszolgáltatásokkal történő kommunikációnak. UDDI – A webszolgáltatásokat ezen protokoll segítségével teszik elérhetővé. Lehetővé teszi, hogy információt keressünk webszolgáltatásokról, így segítve a döntést, hogy felhasználjuk-e őket.
•
WS-Security – A Web Services Security (Webszolgáltatás biztonság) prtotokollt az OASIS szabványként fogadta el. Lehetővé teszi a felek azonosítását, valamint az üzenetek titkosítását.
3.2.1 ábra : Webszolgáltatások folyamata
3.3 A probléma Az egyszerűen programozható webhozzáférés azt jelentené, hogy a fejlesztők a weben elérhető szolgáltatásokból építik fel az alkalmazásokat, valahogy úgy, ahogy manapság építkeznek a helyi számítógépeken levő előregyártott komponensekből. Tegyük fel a következő helyzetet. Egy szövegszerkesztő program tervezője nem épít feltétlenül helyesírás ellenőrzőt a programba, legfeljebb egy nagyon kezdetleges változatot. Így a felhasználónak interneten kell néznie egy erre a célra fejlesztett programot. Azonban a webhely használatához fizetni kell, és jelenleg csak ember használhatja a böngészője segítségével. Ha az üzemeltető a programok számára is lehetővé tenné az adatokhoz való hozzáférést, biztosan több pénzt keresne. Az ilyen programok fejlesztéséhez a programozóknak gyorsan és könnyen kellene tudniuk olyan kódot írni, amely az interneten keresztül más programokkal kommunikál. Az ötlet nem új, sokféle technika létezik az ilyen típusú kommunikációra : RPC, DCOM, MSMQ. Igazán univerzális programozott internet hozzáférésre van szükségünk, olyan módszerre, amelyben az egyik gépen futó program tetszőleges másik gépen meg tud hívni egy valaki más által megirt függvényt.
3.4 A megoldás A Microsoft kidolgozta a webszolgálatatások (webservices) koncepcióját. A webszolgáltatás olyan eljárás, amelynek segítségével a kiszolgálón levő objektumok bejövő kéréseket fogadhatnak az ügyfelektől az internet legkisebb közös nevezőjét, a HTTP / XML kombinációt felhasználva. A webszolgáltatások létrehozásához nem kell új programozási módszert megtanulni. Egyszerűen írni kell egy .Net objektumot, majd meg kell jelölni egy attribútummal, amely jelzi, hogy webes ügyfelek számára is hozzáférhetővé kívánjuk tenni. Az ASP.NET elvégzi a többi munkát. Ehhez is tartalmaz előregyártott infrastruktúrát, amely HTTP-n keresztül fogadja a bejövő kéréseket, és átalakítja őket olyan hívásokká, amelyek az általunk írt objektumnak szólnak. 1 . H T T P - k é r é s e k ér k e z n e k a z U R L - b e v a g y k ül ö n áll ó X M L - b e k ó d o lt m et ó d u s ne v e k kel és p ara m étere k k e l
Windows alapú kiszolgálógép .Net-tel
5 . A z A S P. N E T a z ere d m é n y e k et X M L f or m át u m b a ala k itja, é s a H T T P - p r ot o k o l l al v i s s z a k ü l d i az ü g yfélnek A z o b j e kt u m v i s s zaa dja az ere d m é n y e k et a z A S P. N E T - n e k
2. A z A S P. N E T l étre h o z z a a z . A S M X fájl b a n m e g a d ott o b j e kt u m ot
3. A z A S P. N E T m e g h i v j a a z o b j e kt u m m e g a d ott m e t ó d u s át A s a j át . N et o b j e kt u m 1 . m et ó d u s . .
3.4.1 ábra : Az ASP.NET webszolgáltatásainak kiszolgálóoldali nézete Ha az objektumokat a webszolgáltatásokba építjük, azok bármilyen más rendszerrel együtt tudnak működni a weben, ha a másik oldal is beszéli a HTTP-t és az XML-t. Ezt a feltételt a világon szinte mindenki teljesíteni tudja, az operációs rendszertől és programfuttatási környezettől függetlenül. Nem szükséges tehát teljes infrastruktúrát építeni a webes kommunikációhoz, mert ezt a .Net keretrendszer már megtette. Az ügyféloldalon a .Net olyan osztályokat tartalmaz, amelyek segítségével egyszerűen, függvényhívásokon keresztül hozzá lehet férni bármely, HTTP-kéréseket fogadni képes kiszolgáló által nyújtott webszolgáltatáshoz (3.4.2 ábra). A fejlesztőeszköz elolvassa a webszolgáltatás leírását, és olyan proxyosztályt hoz létre, amely az ügyfélprograméval egyező nyelvű függvényeket tartalmaz. Ha az ügyfél meghívja e függvények valamelyikét a proxyosztály HTTP-kérést generál, és elküldi a kiszolgálónak. Miután a válasz megérkezik a kiszolgálótól, a proxyosztály elemzi az eredményeket, és visszaadja azokat a függvénynek. Ezzel lehetővé válik, hogy a függvényalapú ügyfél zökkenőmentesen kommunikáljon bármely HTTP-t és XML-t értő, vagyis gyakorlatilag valamennyi kiszolgálóval.
0.A programozás alkalmával a fejlesztő proxyosztályt generál a webszolgáltatás leírásából
Ügyféloldali program 1 . A z ü g y f é l f utá s i d ő b e n l étre h o z z a a p r o x y o b j e kt u m o t, m a j d 2. m e g h i v j a a p r o x y n talál h at ó m e t ó d u st
F o r gal o m a k i s z o l g á l ó h o z , ill et v e a k i s z o l g á l ót ó l a z i nter n ete n k e r e s zt ü l
Proxyobjektum
5. A z ü g yfél m e g ka pja a v i s s z atérité s i érté k et a p r o x yt ó l
3. A p r o x y o b j e kt u m a h i v á st X M L f or m át u m b a a l a k itja é s htt p p r ot o k o l l a l e l k ü l d i a k i s z o l g á l ó h o z a z i nter n ete n k e r e s zt ü l. 4. A p r o x y o b j e kt u m X M L f or m át u m b a n m e g k a p j a a z er e d m é n y e k et a htt p p r ot o k o l l o n k e r e s zt ü l. E z t a f ü g g v é n y v i s s z atéré s i érté k é v é a l a k itja
3.4.2 ábra : Az ASP.NET webszolgáltatások ügyféloldali része Irodalomjegyzék :
•
David S. Platt : Bemutatkozik a Microsoft .NET
•
wikipédia
•
egyéb internet források
