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

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

3. 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 Basic-
ben í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 Ú j , c s a k a C L R által
(f ájl m e g n y itá s ) e l v é g z é s e s z o l g á ltat ott m ű v e l ete k,
C L R k ö z v etité s é v e l p é l d á u l a s z e m ét g y ű jté s

Operációs rendszer
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 JIT forditó

K ü r n y e z et s p e c ifi k u s
B a s i c , C++, C o b o l M SIL f uttat hat ó k ó d
st b.

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ű DLL-
assemblyt, 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 GAC-
bó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 Felügyelt halom

Public Sub foo 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
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
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.
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ő
2. A bongésző elküldi a kérést a kiszolgálónak
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

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
Kiszolgáló
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 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
4. A b ö n g é s z ő m e g f o r m á z z a é s
k ért a d at o k at tartal m a z ó o l d a lt.
m e g j e l e n iti a z o l d a lt a z ü g y f é l n é l.

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.

<ht m l st y l e=”c o l or :#000 0 F F ; ”>

T h e ti m e i s : <% =ti m e %> o n <% =date %>
</ht m l>
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 ASP-
ben 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
Olvasható Label – Címke Olyan szöveg megjelenítése,
szövegmegjelenítés amelyet a felhasználó nem
tud közvetlenül szerkeszteni
Szöveg szerkesztése TextBox – Szövegmező Tervezési időben megirt
szöveg megjelenítése,
amelyet a felhasználó
futásidőben és programozott
módon szerkeszthet.
Választás listáról DropDownList – Lehetővé teszi, hogy a
 Legördülőlista felhasználó listából
válasszon vagy szöveget
írjon be
ListBox – Listamező Választási lehetőségek
listáját jeleníti meg. A listán
egyszerre több elem is
kiválasztható
Grafika megjelenítése Image – Kép Kép megjelenítése
Adrotator – Képsorozat Képek sorozatának
megjelenítése
Értékek beállítása 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
RadioButton – Rádiógomb megjelenítése,
Rádiógomb amely ki és bekapcsolt
állapotban lehet
Dátum megadása Calendar – Naptár Lehetővé teszi a
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
Navigáció Hyperlink – Webes hivatkozások
Hiperhivatkozás létrehozása
Táblázatvezérlő elemek Table – Táblázat Táblázat létrehozása
TableCell – Új cella létrehozása táblázat
Táblázatcella egyik sorában
TableRow – Táblázatsor Új sor létrehozása a
táblázatban
Csoportosítás CheckBoxList – Jelölőnézetek csoportba
Jelölőnézetlista szervezése
RadioButtonList – Rádiógombok csoportjának
Rádiógomb lista létrehozása. A csoporton
belül csak egy gombot lehet
kiválasztani
Listavezérlő elemek Repeater – Ismétlő 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
DataList – Adatlista 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
 DataList vezérlőelemmel
meghatározhatjuk a
szövegszerkesztés
viselkedését is
DataGrid – Adatrács 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 Kiszolgáló

1 . A z ü g y f é l k éri a z el s ő o l d a lt 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
M u n k a m e n et a z o n o s it ó s üti
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.

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
4. A z ü g y f é l k ér i a m á s o d i k o l d a lt, 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ő
e n n e k s o r á n v i s s z a k ü l d i a s ütit. 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 2. A z A S P. N E T é s z l e l i, h o g y v é d ett
al k a l m a z ó o l d a lt k ér 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
3. A p r o g r a m o z ó b e k ér i a
s üti v i s s z a k ü l d é s e
fel h a s z n á l ó a z o n o s it ót é s a j el s z ót a
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 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 lj ut a k i s z o l g á l ó h o z 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;
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 k i s z o l g á l j a a k ér é st
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. 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.

<auth o ri z ati o n>

<all o w u s er s=” S i m b a ” r o l e s=” D o c t o r s ” />
<den y u s e r s=” * ” />
<auth o ri z ati o n>
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 Windows alapú kiszolgálógép .Net-tel

U R L - b e v a g y k ül ö n áll ó
X M L - b e k ó d o lt 2. A z A S P. N E T l étre h o z z a a z
m et ó d u s ne v e k kel és
. A S M X fájl b a n m e g a d ott
p ara m étere k k e l
o b j e kt u m ot

5 . A z A S P. N E T a z
3. A z A S P. N E T m e g h i v j a 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 o b j e kt u m m e g a d ott m e t ó d u s át
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 s a j át . N et o b j e kt u m
A z o b j e kt u m
v i s s zaa dja az 1 . m et ó d u s
ere d m é n y e k et a z
A S P. N E T - n e k .

.
 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 F o r gal o m a

k i s z o l g á l ó h o z , ill et v e
p r o x y o b j e kt u m o t, m a j d
a k i s z o l g á l ót ó l a z
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 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