Manapság egyre többet hallani az interneten terjedő férgek által okozott károkról, és a szoftverek biztonsági hibáit kihasználó módszerekről. A vállalatok rendszergazdái szüntelenül azon dolgoznak, hogy a rájuk bízott gépparkok számítógépein ne okozhasson kárt illetéktelen behatoló. A védelem első bástyája már hosszú idők óta a tűzfalak képében jelentkezik, amik meggátolják, hogy hálózati kommunikáció folyjon le azokon a csatornákon, amelyeket nem tekintünk szükségesnek IT folyamataink, és a felhasználók alapvető informatikai igényeit tekintve. A Microsoft az utóbbi időben fokozottabb figyelmet szentel alkalmazásainak és operációs rendszereinek védelmére. A Windows XP második javítócsomagja több lényeges biztonsági rést foltozott be, és egyszerű eszközökkel segíti az átlagfelhasználó tájékozódását saját számítógépének biztonsági beállításai között. A Microsoft megoldások szerveroldalát képező Windows Server 2003 is számos biztonsági szolgáltatással rendelkezik, azonban egy teljes informatikai hálózat biztonsági problémáinak általános kezelésére ezek közel sem elegendőek. A Microsoft közel négy éve jelentette meg az ISA Server 2000 néven ismert tűzfalmegoldását, mely egyszerű felület segítségével tette lehetővé a hálózaton átfolyó csomagok útjának szabályozását. Mint minden első generációs termék, ez is komoly hiányosságokkal rendelkezett számtalan területen; rugalmasság terén nem volt képes felvenni a versenyt a Linuxon, és más platformokon elérhető szoftverekkel. Az ISA Server 2004 / 2006 már nem csak egyszerű kezelhetőségével, de aprólékos konfigurálási lehetőségei révén is erős ellenfele a konkurens termékeknek, és végre bármilyen hálózati topológiára alkalmazhatóak biztonsági szolgáltatásai. A modern tűzfalak két alapvető módszert kínálnak a problémák leküzdésére: az általánosabb megoldás a beérkező adatcsomagok fejlécét vizsgálva, annak küldőjének és úticéljának meghatározása után dönti el, hogy az adott csomag továbbítható-e, illetve milyen -- az eredetileg meghatározottól eltérő -- célponthoz jusson el. A másik, modernebb személet a csomagok tartalmát is vizsgálja, és képes észlelni az amúgy veszélytelen csatornákon közlekedő kártékony adatokat. Utóbbi megoldással könnyedén megállíthatóak a Nimdához és a Code Redhez hasonló vírusok, amelyek kifejezetten az OSI-ISO modell alkalmazási rétegegében vernek tanyát, és ez által a korábbi tűzfalak számára észrevétlenek tudnak maradni.

Mi is az ISA Server?

Az Internet Security and Acceleration Server 2004 / 2006  egy bővíthető, nagyteljesítményű tűzfal és web gyorsítótár kiszolgáló, mely kihasználja a Windows 2003 Server más szolgáltatásait (pl. RRAS, VPN) biztonsági beállításait, menedzselhető képességeit és a címtárat, azért hogy megvalósulhasson az internet elérés házirendalapú szabályozása, gyorsítása és menedzselése. Csökkenti, vagy szinte teljesen megszünteti (teljesen megszüntetni persze lehetetlen), az internettel kapcsolatos biztonsági vagy teljesítménnyel összefüggő problémákat, segít megvédeni a hálózat erőforrásait az illetéktelen felhasználóktól, alkalmazásoktól. Csekély sávszélességű internet hozzáférés esetén (64K/128K) rendkívül hasznos szolgáltatása, hogy web gyorsítótára gyorsabb webelérést biztosít a felhasználóknak oly módon, hogy a kérések egy részét a leterhelt internet vonal helyett a helyi gyorsítótárból szolgálja ki. Akár összetevőnként, akár összefűzve integrált tűzfal- és gyorsítótár kiszolgálóként helyezzük üzembe.

Az ISA egységes grafikus konzolt biztosít, mely egyszerűbbé teszi a rendszergazda munkáját.
Internet tűzfal

Többrétegű tartalomfigyelés (csomag-, kapcsolat-, és alkalmazásszintű szűrők)
Intelligens adatfelismerő alkalmazásszűrők
Beépített behatolás észlelés
Beépített virtuális magánhálózat (VPN) lehetőségek

Biztonságos kiszolgáló-közzététel
Könnyen használható "Kiszolgáló közzététele" varázslók
SecureNAT az ügyfelek számára észrevétlen kapcsolatokhoz és kiszolgáló közzétételhez.
A közzétehető szolgáltatások között megtalálható a HTTP, HTTPS, FTP, SMTP, POP3, H.323 (NetMeeting), folyamatos átviteli szolgáltatások (media streaming), stb.

Belső ügyfeleket kiszolgáló gyorsítótár
A gyorsítótár egy része a RAM-ban helyezkedik el
Időzített letöltések a gyorsítótárba (Scheduled Content Download)
Elosztott és hierarchikus gyorsítótár láncok létrehozásának támogatása
A népszerű webhelyek tartalmának előzetes (pl. éjszakai) automatikus letöltése (Active Caching)

Külső ügyfeleket kiszolgáló gyorsítótár
Web közzététel varázslók
A gyorsítótár egy része szintén a RAM-ban helyezkedik el
A külső ügyfélek számára láthatatlan
Elosztott gyorsítótár kialakítása a Caching Array Routing Protocol (CARP) segítségével

Integrált tűzfal és web gyorsítótár kiszolgáló
Aprólékos, házirendalapú hozzáférési szabályok
Sávszélesség-szabályozás
Vállalati és tömbszintű házirendek
Naplózás és jelentések készítése
Active Directory integráció (nem alapkövetelmény)
Központosított Microsoft Management Console (MMC)

Az ISA Server típusai

Kétfajta változatot ismerünk ebből a termékből: a Standard és az Enterprise verziót. A különbség az alapszolgáltatások tekintetében nincs, ami van, az "csak" funkcionális. Az utóbbi változat elsősorban nagyvállalati környezetbe készült, ennek megfelelően támogatja a következő szerepköröket.

1. Az ISA tömbök (array) alkalmazását, és így például a tömbben lévő ISA szerverek működésének központi, házirend alapú kényelmes szabályzását.

2. A visszirányú web gyorsítótár (reverse cache) terheléselosztásos (NLB = Network Load Balancing) módszerrel történő használatát, ami a webszerverek folyamatos elérhetősége és magas rendelkezésre állása miatt alkalmazható.

3. Jelen van az Enterprise változatnál a CARP protokoll, amely az esetleges brutális mértékű, több szerverre elosztott web gyorsítótár kialakítását teszi lehetővé.

4. Nem korlátozza a használható CPU-k számát (a Standard változatnál maximum 4 CPU-t használhatunk).

Az Enterprise változat kizárólag tartományvezérlőre telepítve működik (a használatához egyébként ezért még egy sémabővítésre is szükség lesz), míg a Standard-nál ez nem követelmény (csupán a tartományi tagság az), de nem is kizáró ok.
Természetesen Windows Server 2003 alatt is tökéletesen működik a szoftver, amennyiben az ISA Service Pack 1 és az isahf255.exe nevű patch fel van telepítve. Ezeknek a patch-eknek a telepítésére figyelmeztet is a telepítő. Ezeket a komponenseket (több más ISA-hoz használható eszköz mellett) megtalálhatjuk, és letölthetjük a Microsoft honlapjáról.
A szoftver telepítési módjai

Azt, hogy milyen üzemmódban működik az ISA, a telepítés során kell meghatároznunk, ennek módosítására a későbbiekben nincs is lehetőség, tehát jól fontoljuk meg, mit választunk az alábbiakból:

• Gyorsítótár mód (csak a hálózati teljesítmény növelése a web cache-sel).
• Tűzfalmód (csak a biztonságos Internet elérés és a belső szerverek védelme).
• Integrált mód (az előző kettő kombinációja, általában, és egy darab ISA szerver esetén ez az ajánlott).

A cím nem elírás, tényleg van egy nyílt forráskódú project amely Microsoft .NET keretrendszer segítségével készítenek egy operációs rendszert. A projekt neve SharpOS, és ahogy a neve is sejteti C# nyelven írják. A projekt már egy két mérföldkövet megélt, de még mindig kezdetleges állapotban van, még csak a kernelt meg néhány alap funkciót valósítottak meg. Mindenesetre egy fantáziadús kezdeményezés, és bárki aki kedvet és elég elhívatottságot érez magában beleszállhat a fejlesztésbe.

További információk a projektről: http://www.sharpos.org/redmine/wiki/3
ScreenShotok: http://www.sharpos.org/redmine/wiki/3/Media_Screenshots

Kevés xbox360 tulajdonos tudja pontosan, hogy az ő X-boxa mire is képes. Hisz egy xbox nem csak egy játékgép, hanem komplett média központ is. Akár, hálózaton keresztül, hallgathatjuk kedvenc zenéinket egy jól megérdemelt FIFA-zás vagy épp PGR4 közben. És persze most már avi-t is lejátszhatunk vele, ha akarunk. De ezenkívül az Xbox360, még rendelkezik egy komplett Windows Media Center képességgel is. Mindösszesen a belső hálózatunkon az egyik PC-nek rendelkeznie kell egy Media Centerrel. Tehát egy Windows Vista Ultimate, Home Premium vagy ép Windows XP WMC editionnek kell rajta futnia, és már is használható az X-box 360 Media Centerként. Így minden pc-s multimédiás tartalmat akár TV előtt is megtekinthetjük. Ahhoz, hogy ezt beállíthassuk a következő lépéseket kell elvégeznünk.

1) Indítsuk el az X-boxot majd a Media fül alatt, válasszuk ki a Media Center menüpontot.

2) A következő képernyőn a Windows Media Centerre kattintsunk. (A)

3) Kapunk egy setup kulcsot. Ezt jegyezzük meg, mert a későbbiek folyamén szükségünk lesz erre.

4) A rendszer szól, hogy további információkat, hol találunk, illetve a PC-re ne felejtsük feltelepíteni a Media Centert.

5) A PC-ken, indítsuk el a Windows Media Centert.
Most induláskor jön egy üzenet, hogy érzékelte a rendszer, hogy a hálózaton van egy X-box. Be szeretnénk-e ezt állítani?
- Kérdezi a WMC. :)
Természetesen be.
Kattintsunk a Yes gombra.

6) Üdvözlő képernyő. Érdemleges információt nem mond el a számunkra, amit eddig ne tudtunk volna. Next gomb.

7) Ezen a formon kell megadnunk, az x-box által közölt setup kulcsokat. Csak ezen 8 számjegyű kulcsok segítségével tudunk majd kapcsolódni az X-boxhoz.

8) Újabb fontos információkat nyújtó képernyő. De a gyengébbek kedvéért nem árt. Kattintsunk a NEXT-re.

9) A képernyő szintén értelemszerű. Válasszuk ki a YES-t. (De itt jegyezném meg, hogy érdemes olyan x-boxal rendelkezni, amin van merevlemez. Nem kötelező, de érdemes.) Kattinsunk a NEXT gombra.

10) Beállítások végrehajtása következik. Ez eltárhat egy darabig. (Média tartalom mennyiségétől függően 5-10 perc)

11) A beállítások végeztével, már a TV-n láthatjuk a Media Center képét. És mindent elérhetünk rajta keresztül, legyen az a kedvenc sorozatunktól kezdve, a családi fotónkon át bármi. Sőt akár rádiót vagy TV is nézhetünk ez által, ha a PC-nkben van TV/Sat kártya.

11 egyszerű lépéssel a mi kis X-boxunkból egy komplett házimozi rendszert alkottunk. És 70-80 ezer ft-ot külön Media Center PC beüzemelésére.

Sokakban felmerülhet a kérdése, hogy oké szép, és jó ez a WCF de vajon milyen a teljesítménye a Remotinghoz vagy adott esetben az ASMX-es web szolgáltatásokhoz képest? Nos a választ az, hogy szinte minden teljesítmény mutatója jobb mint az ezelőtt használt technológiáké. De nézzük számokban kifejezve.

Az összes összehasonlítás a teljesítménybeli különbségeken alapszik. A grafikonokon a WCFnek egy-egy másik kommunikációs technológiával való összehasonlítását látjuk. A függőleges tengelyek skáláját a másodpercenként elvégezhető műveletek számát, mint teljesítménymérő értékek képzik. Minél nagyobb egy grafikonon a megjelenítendő oszlop, annál nagyobb teljesítménnyel bír a neki megfelelő technológia.

ASMX vs. WCF

A gazdakörnyezet egy IIS 6.0, és nem voltak biztonsági megszorítások. A WCF által használt kötés a http protokollon alapuló BasicHttpBinding volt. Mint látható a WCF rendre 27,30,és 40 százalékkal hatékonyabb volt mint az ASMX web szolgáltatások.

.NET Remoting vs. WCF

Ebben az esetben sem voltak biztonsági megszorítások, valamint a WCF-hez használt kötés a netNamedPipeBinding volt. Ugyanis mind a kliens mind a server ugyanazon gépen futott.

Az esetek túlnyomó többségében a WCF lényegesen hatékonyabb megoldást nyújt a már létező .NET technológiákkal szemben.

További összehasonlítások, és a teszt részletei a: http://msdn2.microsoft.com/en-us/library/bb310550.aspx címen

A WCFhez nagyon sokféle tool és adminisztrációs eszközök áll a rendelkezésünkre, melyek segítságável a fejlesztést és a hibakeresést leegyszerüsítik. Ilyen eszközök például:

• Trace
• Message Loging
• Event log
• WMI
• Preformanica számlálók

Trace

Ha fut a WCF szolgalátás és WCF fut a kliens. És mind a kliens mind a server oldalon fut a WCF runtime ami részletesen naplózza a tevékenységeit. Trace adatok a WCF rendszereknél a debugolás alternatívája, hisz lehetőséget biztosít számunkra az esetleges teljesítmény problémák és az alkalmazás problémáinak felderítésére. Rugalmasan konfigurálható. A tracelést engedélyeznünk kell az app.config -ban vagy adott esetben a web.config -ban. De a Service Configuration Editorral is megoldható. Ha szükséges a következő névtereket használhatjuk fel:
System.Diagnostics.TraceSource ,System.Diagnostics.TraceListener

Message loging (üzenetek naplózása)

A kliens és a szolgáltatás közötti üzenet váltásokat naplózza. Így láthatjuk az üzeneteket, hogy mik mentek ki és jöttek be. Láthatjuk akár nyers XML formában is. Így akár a helytelenül formázott üzeneteket is megtekinthetjük. Kiderül, hogy az adott üzenet titkosított volt e vagy sem, és ezenkívül számos más hasznos szolgáltatást biztosít a számunkra.
Ha meg akarjuk tekinteni ezeket az üzeneteket akkor egy SDK tool segítségével tehetjük meg. Ez pedig a Service Trace Viewer. Fontos megjegyezni, hogy mind a szolgáltatás mind a trace esetében rögzítettek a trace adatok

Event log

Windows esemény naplóba bekerülnek azok az események, amelyek valamilyen hibára vagy problémára utalnak (De nem csak ezek kerülhetnek be, hanem pl. a fejlesztők az üzenetek traceleést engedélyezi). Az eventlogba való naplózás mindig be vak kapcsolva és nem tiltható le.

WMI - Windows Management Instrumentation

Futás közbeni információt szolgáltat a szolgáltatásokról. Pl.: kilistázhatjuk, hogy épp milyen szolgáltatás fut és ezeknek mik a tulajdonságai konfigurációi. Ezenkívül a WMI segítségével távoli felügyeletet is támogat valamint nagyon jól scriptelhető. A WMI-t is engedélyeznünk kell mégpedig az app.config -ba vagy web.config –ban kell.

Egy nagyon jó felhasználása akkor van, ha futás közben szeretnénk bekapcsolni az adott szolgáltatásnál a tracet. Így nem kell leállítanunk majd újraindítanunk az adott szolgáltatást.

Performanica számláló

Külön engedélyeznünk kell.

Megtekinthetjük például, hogy egy adott szolgáltatáshoz mennyi hívás érkezet, mennyi idő alatt futottak be, megtekinthetjük azt is hány hívás nem sikerült végrehajtani. stb.

Ezek a legfontosabb trace eszközök,de a Microsoft SDK 6.1 ennél sokkal több toolt bocsájt a fejlesztők rendelkezésére.

Most, hogy elkészítettük az előző blogpostban a BasicHttpBinding alapú példaprogramot, alakítsuk kicsit át. Mert tegyük fel, hogy elkészítettük az alkalmazásunkat és már élesben is működik, de jön a főnök, hogy srácok változott a felállás, nem jó az, hogy http alapú kommunikációt használunk. A TCP sokkal jobb volna. Muszáj átírnotok az egész alkalmazást. Át is kellet volna írnunk az alkalmazásunk nagy részét, ha nincs a WCF. Ugyanis most már csak néhány sort kell, átírunk a szolgáltatás konfigurációs állományába vagy esetlegesen néhány sort az alkalmazás forráskódjában. Írjuk is át.

Server

1. Térjünk vissza a szolgáltatás forráskódjához. (WCFCalacServer)

2. Nyissuk meg az app.config-ot és írjuk át a következő sorokat.
A mexHttpBinding –ot mexNamedPipeBinding –ra. Ugyanis jelen esetben a szolgáltatás és kliens egy azon gépen fog futni.

3. Ezen kívül még a serviceMetaData sorhoz adjunk hozzá egy httpGetUrl tagot és adjunk neki egy http címet. Ezen címen fogjuk letölteni majd a meta adatokat, amelyeknek szüksége lesz a kliensnek.

4. Ha ezzel megvagyunk, nézzük meg a forráskódunkat. Az Address jelen esetben meg fog változni, hisz nem http alapon történik a kommunikáció. Tehát meg kell változtatnunk. De gondoljunk bele ez elég rugalmatlan. Hisz az alkalmazásunk, ha elkészül, után minden esetben újra és újra le kell fordítanunk, ha más címet szeretnénk biztosítani a számára. Így tegyük azt, hogy a címet elhelyezzük az app.configba. Mégpedig a következőképpen:

5. Láthatjuk, hogy jelen esetben a cím net.pipe:// -re kezdődik. Ez a NamedPipeBinding miatt kell.

6. A teljes konfigurációs állomány kb. így fog kinézni:

7. Ahhoz, hogy az alkalmazásunkba ezt a címet felhasználjuk a következő lépéseket kell megtennünk.

• A Solution Explorerbe jobb egérgomb a references-re majd Add references menüpont.
• A megjelenő listából válasszuk ki a System.Configuration névteret és adjuk hozzá.
• Usingoljuk be System.Configuration-t
• Írjuk át az Uri-t a következőképpen

• 5) Mostantól kezdve kicserélhetjük a címet a konfigurációs állományba, és nem kell újra lefordítanunk hozzá az alkalmazásunkat.

8. Most már csak annyi a teendőnk, hogy az eddig használt bindingot kikommentezzük és az új bindingot példányosítjuk.

9. Ha ezzel is megvagyunk, indítsuk el az alkalmazásunkat. Figyeljünk oda, hogy ha van tűzfalunk akkor az szólni fog, hogy egy alkalmazás elindult és engedélyezzük-e az alkalmazás számára a kommunikációt. Itt válaszoljunk igennel, különben nem fogjuk tudni elérni a kliensből a szolgáltatást.

Kliens

1. Térjünk vissza a klienshez és töröljük a solution explorerből az ott lévő szolgáltatást.

2. Majd kattintsunk újra jobb egérgombbal a refererencesre és válaszuk ki az Add Service Reference menüpont.

3. A megjelenő ablakba adjuk meg azt az URL címet amit a szolgáltatás kofigurációs fájlában a serviceMetdata-nál megadtunk. Jelen esetben a: http://localhost:8880/Calc -ot. Majd a névterét nevezzük el úgyanúgy mint az előzőt, tehát „szolgaltatas” legyen a neve.

4. ha ezzel meg vagyunk akár el is indíthatjuk az alkalmazásunkat. És most már tcp-n keresztül fognak kommunikálni.

Így azért sokkal hatékonyabb a munka, hogy nem kell külön szolgáltatás írnunk ahhoz, hogy TCP/IP vagy épp HTTP alapon történjen egy kliens és egy szolgáltatás között a kommunikáció.

A WCF bemutatásaként először egy egyszerű számológép alkalmazást fogunk elkészíteni, aminek megírjuk a server részét. Majd a kliens oldalon megnézzük, hogy hogy hívjuk meg az adott szolgáltatást.

Indítsuk el Visual Studio 2008-at. Ha Windows Vistat használunk rendszergazdai módban indítsuk el. Hozzunk létre egy új solutiont. El kell döntenünk, hogy hogy fogjuk hosztolni a szolgáltatásunkat. Ha először még nem tudjuk eldönteni hozzunk létre egy osztályt és abban valósítsuk meg a szolgáltatást. Az egyszerűség kedvéért első körben hozzunk létre egy console alkalmazást. Szolgáltatásunk jelen esetben egy egyszerű számológép szolgáltatás lesz.

Server

1. Ha kész a solution legyen a neve a WCFCalacServer, majd adjuk hozzá System.ServiceModel névteret. Erre névtérre van szükségünk, hogy WCF tudjunk létrehozni. 

2. Készítsünk egy új osztályt melynek neve legyen a Calculator.cs

3. Az osztályhoz adjuk hozzá a következő kódot:

A kód egy egyszerű összeadás és kivonás metódust valósít meg

1. Ha ezzel megvagyunk, ahhoz hogy tudjuk WCF szolgáltatásként publikálni, fel kell ruházni a megfelelő contractokkal az osztályt és annak metódusait (illetve ha szükséges a többi elemeit a megfelelő contractokkal).

2. Tehát az osztály neve elé a ServiceContract attribútumot kell adnunk. A metódusok elé pedig OperationContract attrbiutumot. Figyeljünk oda, hogy nem lehet olyan ServiceContractal minősített osztály amelyben legalább egy operationContract attribútummal ellátott osztály sincs.

3. Most, hogy a szolgáltatás osztállyal kész vagyunk. A szolgáltatásunkat hosztolni kéne. Térjünk vissza a Program.cs be majd írjuk meg a következő kódot:

4. Létre kell hoznunk egy Uri objektumot, amelynek paraméterének, átadjuk, hogy a szolgáltatásunkat milyen címen fogjuk publikálni. (Address)
Szükségünk lesz egy ServiceHost objektumra is, ennek a paramétere a szolgáltatás osztályunk típusa, illetve az Uri cím lehet.
Ha ezzel megvagyunk, meg kell adnunk a bindingot. Jelen esetben a BasicHttpBinding –ot választottuk.
A serivceHost objektumnak meghívjuk az AddServiceEndpoint metódusát, amelynek szintén átadjuk a szolgáltatás osztályunk típusát, és címét valamint itt adjuk meg a kötést is.

5. Ha ezzel meg vagyunk, az Open metódussal elindítjuk magát a szolgáltatást.
Célszerű try catch blokkokba pakolni a kódot, hogy minden esetleges hibát lekezeljünk.

6. Indítsuk el a szolgáltatást. Azt hinnénk, hogy már minden működik, de még hátra van egy lépés.

7. Indítsuk el a böngészőt, majd adjuk meg a szolgáltatásunk címét. Ekkor egy barátságtalan de annál informatívabb képernyő fogad. Amely szerint nincs engedélyezve a szolgáltatásunk, és azt is elmondja nekünk, hogy legegyszerűbben, hogy oldhatjuk meg a problémát. Sőt még minta példát is mutat. Így ezt a példát másoljuk most ki, és hozzunk létre egy app.config fájlt.

8. Az app.configban finomra hangolhatjuk a szolgáltatásunk beállításait. Most az egyszerűség kedvéért csak a szolgáltatás elindításával törődünk.
A <service name="MyNamespace.MyServiceType" helyére kell beírnunk WCFCalcServer.Calculator –t.

9. Ha ezzel is megvagyunk akkor kész a szolgáltatásunk amit már használhatunk is.

Kliens

1. Indítsunk egy új Visual Studio-t és hozzunk létre egy új Console Applicationt. A neve legyen, mondjuk a WCFCalcClient.

2. Kattintsunk a Solution Explorerbe a Referencesre jobb egérgombbal, majd válasszuk ki az Add Service Reference menüpont.

3. A megjelenő ablakba adjuk meg a szolgáltatásunk címét. Majd kattintsunk a Go gombra. Fontos: A szolgáltatásnak futnia kell!

4. Az ablak alján adjuk meg a szolgáltatásunk nevét, amelyen keresztül hivatkozhatunk rá. Az egyszerűség kedvéért most nevezzük el szolgáltatásnak.

5. Térjünk vissza a Program.cs –hez, és adjuk hozzá a következő kódot a main részhez: (Az osztással még nem foglalkozunk)

6. Az eredményt pedig a következő képen láthatjuk. Mint ezen egyszerű példán is látjuk a WCF segítségével nagyon könnyen és hatékonyan tudunk elosztott alkalmazásokat készíteni

Már nagyon korán az informatika aranykorának hajnalán felmerült az igény arra, hogy az alkalmazások egymással kommunikáljanak. Több kommunikációs technológia alakult ki az idők folyamán volt, amelyek sikeresek voltak és voltak olyanok amelyek szinte azonnal elhaltak. Csak egy pár említésre méltó technológia, OLE, COM, DCOM majd a nagy előre lépés a Remoting. Sokáig ezek a technológiák uralták a piacot, de elég nehézkes volt a kezelésük , tanulásuk, megértésük. Majd ahogy a piac igénye nőttek egyre kiforrtabb technológiák álltak a fejlesztők rendelkezésére. Emlékezzünk vissza a 2000-es évek elején a web szolgáltatások megjelenésével már egyszerűen tudtunk más platformokon futó alkalmazásokkal is kommunikálni, hisz a kommunikáció alapja szöveges vagy nyers XML formában történt. És nem bináris alapú volt mint a DCOM esetében. De a kommunikáció még mindig nagy  probléma volt, hisz az egyes kommunikációs technológiák elsajátítása komoly utánajárást és szakértelmet igényelt. És ha szükség volt egy Remotingot használó alkalmazásra vagy egy web szolgáltatást publikáló alkalmazásra sok esetben nem volt meg a megfelelő tudás a kezünkben. Ezzel szemben a WCF a kommunikációs problémákra teljes körű megoldást kínál. Talán a WCF egyik legfontosabb újítása, hogy innentől kezdve a fejlesztőnek nem kell törődnie azzal, hogy a kommunikáció hogy valósul meg TCP/IP alapon vagy HTTP vagy esetleg más alapokon. A kód ugyan az marad. Ha át akarjuk írni, optimális esetben ezt megtehetjük vagy a konfigurációs fájlból, de a programban is csak néhány sort kell változtatnunk.

És hogy mégis hogyan működik a WCF? Egyáltalán mi is ez a WCF? Ezt fogjuk megnézni ebben a blog bejegyzésben.

Windows Communication Foundation (CodeName: Indigo)

A WCF a .NET Framework 3.0-ban jelent meg először. A WCF segítségével szolgáltatás orientált alkalmazásokat tudunk létrehozni, amelyekkel akár más platformon futó alkalmazásokkal is kommunikálhatnak. Akár Linuxon futó alkalmazásokkal is hatékonyan tud együtt működni. Tehát a WCF nem más mint egy újgeneráció technológia elosztott alkalmazások fejlesztéséhez.

A WCF egy egységes programozási modellt nyújt a fejlesztők számára. Így ugyanabban a környezetben tudunk fejleszteni, ha web szolgáltatást, enterprise web szolgáltatást vagy épp .NET Remoting alkalmazásokat. Így egy technológia ismeretével a korábbinál kevesebbet kellesz kódolnunk és a hatékonyabban tudunk elosztott alkalmazásokat készíteni. Alapvetően SOA szemléletet követ a WCF, de a SOA -nál többet nyújt. Akár bináris kommunikációra, nyers XML kommunikációt illetve a P2P kommunikációra is képes. A WCF számos szolgáltatást nyújt többek között a biztonság, a tranzakció kezelés és megbízható üzenetkézbesítés területén. Ezen túlmenően teljes körű diagnosztikai funkciókkal rendelkezik (üzenetnaplózás, trace, teljesítményszámlálók, WMI). A WCF igazi keretrendszer: működésének szinte valamennyi aspektusa testre szabható, kiterjeszthető.

A WCF terminológiában két szereplőről beszélhetünk. Van a szolgáltatás (egy- vagy több végpontot publikál) és van a kliens, amely a szolgáltatások végpontjainak üzeneteket küldeni, és a szolgáltatás végpontoktól üzenetet tud fogadni.

Minden végpont 3 dolgot fog össze. Az ABC-t. Azaz az Address, Binding , Contractot.
De mik is ezek?
Az Address a végpont címe. Ez tulajdonképpen egy URL amelynek segítségével elérjük az adott szolgáltatást.
A Binding definiálja, hogy milyen módon történik a kommunikáció. (TCP/IP, HTTP stb.. ) Számos előre definiált Bindingot nyújt a számunkra a WCF.
A Contract a szolgáltatás interfacenek a leírása, azt határozza meg, hogy az adott szolgáltatás milyen műveleteket támogat. Ez definiálható .NET interfacek formájában vagy WSDL nyelvű leírással is. Ez mindegy a számunkra hisz átjárható.

WCF kötések (Binding)

A WCF számos beépített kötés típussal rendelkezik, amelyek a legkülönfélébb transzport protokollokat, titkosítást é s biztonsági előírásokat valósítanak meg. A legtöbb esetben ezek számunkra megfélőek, de ha a helyzet úgy hozza ezek a kötések testre szabhatók, kiterjeszthetők alkalmazás specifikus funkcionalitással, megszorítással. Ismerkedjünk meg néhánnyal.

• BasicHttpBinding – ASMX alapú web szolgáltatásokkal való kommunikációra alkalmas. http protokollokon alapszik és szövege vagy XML formátumú üzenetkódolást definiál. (Alapvető biztonság)
• WsHttpBinding – Biztonságos csak egyirányú (simplex) illetve kérdés/válasz üzenettovábbításon alapuló szolgáltatás szerződések esetén használatos.
• WsDualHttpBinding – Biztonságos, duplex üzenettovábbításra és SOAP alapú kommunikációra használjuk.
• NetTcpBinding – WCF alkalmazások közötti gép-gép kapcsolaton megvalósított biztonságos, megbízható és optimalizált kommunikációra alkalmas kötés.
• NetNamedPipeBinding – Ha egy gépen futó WCF alkalmazás között szeretnénk biztonságos, hatékony és optimalizált kommunikációt megvalósítani.
• NetMsmqBinding – WCF alkalmazások kommunikációját elősegítő, várakozási soron alapuló kötés. A legnagyobb előnye ennek a kötésnek az, hogy ha a szolgáltatás nem is érhető el és a kliens üzenetet küld a szolgáltatásnak, akkor az üzenet nem vész el, hanem a szolgáltatás bekapcsolásakor meg kapja az összes üzenetet.
• NetPeerTcpBinding –Több számítógép között szeretnénk biztonságos kapcsolatot létesíteni.

WCF Architektúra – Csatornák

Most, hogy megismerkedtünk a WCF nyújtotta Bindingokkal, nézzük meg, hogy hogy is történik a kommunikáció, és miért is olyan fontos a binding.

Amikor a kliens meghívja a szolgáltatás valamelyik műveletét akkor a kliens oldalon ezt a kérést a kliens oldalon a channel proxy fogadja, majd átalakítja üzenetté és ez az üzenet végighalad a kliens oldali channel stack egyes rétegein.

Minden réteg valamilyen szolgáltatást valósít meg. Pl. biztonság, megbízhatóság, tranzakció kezelés stb. A legalsó réteg minden esetben a Transport channel mely az üzenetek továbbításáért felelős, amely az üzeneteket adat folyammá alakítja, amit elküld. A szolgáltatás oldalon a transzport channel fogadja az adatfolyamot, majd vissza alakítja üzenetté. És ez az üzenet ugyanúgy végighalad a rétegeken csak itt jelen esetben fölfelé. És végül a Dispatch runtime meghívja a szolgáltatás objektumunk megfelelő műveletét.

Az, hogy hogyan épül fel egy channel stack azt a Binding határozza meg. Például, ha kiválasztjuk a WsHttpBindingot akkor a transzport http alapon valósul meg. Fölötte lesz egy Ws Security réteg fölötte egy realible message réteg, és egy tranzakció réteg. Tehát a Bindingra a csatorna konfiguráció leírásaként is tekinthetünk.

WCF használata

Ahhoz, hogy WCF-et használni tudjuk szükségünk lesz a System.ServiceModel névtérre.

Technikai követelmények:
Operációs Rendszer: Windows Vista, Windows XP SP2 vagy Windows Server 2003 SP1
IDE: Visual Studio 2008 vagy Visual Studio 2005 SP1 with WCF extension
Framework: .NET 3.0 , .NET 3.5
SDK: Microsoft Windows Software Development Kit 6.0

A WCF szerződések meghatározzák az adott szolgáltatás viselkedését. A WCF ötféle szerződést ismer.

· Serive Contract – Szolgáltatás szerződés

· Operation Contract – Művelet szerződés

· Data Contract –Adat Szerződés

· Fault Contract - Hiba szerződés

· Message Contract – Üzenet szerződés

Service Contract
Minden WCF osztály implementál legalább egy Service Contractot, amely a szolgáltatás által publikált műveleteket definiálja. A Service contact egy olyan interface vagy osztály amely a [ServiceContract] attributummal van ellátva.

[ServiceContract]

public class Calculator

{
…
}

Operation Contract
A művelet szerződés a szolgáltatás által definiált műveleteket definiálja. Művelet szerződés olyan metódus, amely el van látva egy [OperationContract] attribútummal az intefaceben vagy az osztályon belül. Fontos megjegyezni, hogy nem csak publikus metódusok lehetnek részei a szerződének hanem private minősítésűek is. (Asmx web szolgáltatásoknál például csak publikus lehetet a [WebMethod])

[OperationContract]

private int MyOperation(…)

{

…

}

Data Contract
Adatszerződésre akkor van szükség, ha a kliens és a szerver közötti csatornán történő kommunikáció során összetett típusú objektumot szeretnénk továbbítani. Egy adatszerződés tehát egy olyan osztály, melyet [DataContract] attribútummal látunk el, adattagjait pedig [DataMember] attribútummal.

[DataContract]

public class MyClass

{

[DataMember]

public string MyVariable;

[DataMember]

public string MyVariable2;
} 

Fault Contract
A WCF alkalmazások úgy kezelik a kivételeket, hogy a menedzselt kivétel példányokat SOAP hiba példányokká képezik le, majd a fogadó ismét menedzselt példányokká képezi le.

[OperationContract]

[FaultContract(typeof(Exception))]

public double MyOperation(…)

{

…
}

Message Contract
Az üzenet szerződés egy teljes SOAP üzenet formátumot definiál. A komplex típusok továbbítására használható csak úgy, mint az adatszerződés, viszont azzal ellentétben a kommunikációs csatornára kerülő SOAP üzenet struktúrájára vonatkozó információk megadását is lehetővé teszi.

Meta adat csere - MetadataExchange

Ha kész a szolgáltatásunk ezt el kell érnünk a kliensből, de ehhez meg kell kapnia a szerződés leírását. Hisz a kliens önmagában, nem tudhatja, hogy mégis milyen távoli metódusokat hívhat majd meg. Ezt valahogy közölnünk kell vele. De, hogyan? Erre több lehetőség is van.

1) Vagy Copy -Pastel beilleszthetjük és meghívjuk. Ez egyszerű, de sok esetben lehetetlen feladat hisz mi van akkor, ha a kliens Java platformon fut? Akkor Hiába kapnánk meg az interfacet.

2) SOA környezetben természetesen van erre megoldás.
1) MetaDataExchange - meta adatcsere végpont. Egy adott címen letölthetővé válnak a szolgáltatás megvalósításának elemei. Visual Studio 2008-ból az Add Service Reference szolgáltatással használható

3) Illetve, ha fejlesztőcsapat másik észét megkérjük, hogy küldje el a számunkra az adott szolgáltatás WSDL vagy XSD leírását.

WCF szolgáltatás publikálása

De hogy publikáljuk a szolgáltatásunkat? Tulajdonképpen szinte bárhogy. Lehet akár egy console alkalmazás, vagy egy windows forms, netalán egy WPF alkalmazás is hosztolhatja. Ezt nevezzük Self- Hostingnak. De akár Windows Service is publikálhatja a szolgáltatást. Vagy akár az IIS is hosztolhatja számunkra a szolgáltatást (IIS 5.1, IIS 6.0). Viszont az IIS 5.1 és 6.0 használatával van néhány megkötés a hosztolással kapcsolatban. Csak HTTP vagy HTTPS alapú kommunikációt lehet megvalósítani, így csak olyan binding használhatunk, ami ezt a kommunikációt valósítja meg. De IIS 7.0 alatt már nincsenek ezek a megkötések ott már lehet használni TCP-t vagy bármely más kommunikációt.

Nem rég megjelent a Windows Vista SP1-es változata. Sőt már fel is került az MSDNAA Szerverekre, így bátran lehet tölteni. Ugyanígy megjelent az XP SP3 -as kiadása. Bár még az integrált telepítő lemezre várni kell egy keveset, de már a telepítők elérhetők.

Akiknek nincs MSDNAA előfizetése azok a Windows XP SP3-t innen is letölthetik. A csomag mérete (~310 MB)

Windows XP SP3 - ENG
Windows XP SP3 - HUN

A Windows Vista SP1 pedig innen érhetőek el:

Windows Vista SP1 - ALL Language x86 (544 MB)
Windows Vista SP1 - ALL Language x64 (873 MB)

De akinek ez se lenne elég, ajánlom figyelmébe a PR marketing osztály legújabb szüleményét. Én már most mondom, hogy sláger gyanús :)

Marketing Video

Kíváncsi leszek, hogy a Music TV-n mikor lesz No'1 :)

UI: Aki megszerzi mp3-ba kérem linkelje be. Metál csengő hang lenne belőle :P