Szerző: Budai Péter

2004. április 26. 09:07

Microsoft Windows Longhorn előzetes

A jelenleg elérhető változat még nem béta, és nem is alpha verzió, hanem egy idejekorán kiadott, kizárólag fejlesztők, és egyéb informatikai szakemberek számára készített szoftver, aminek segítségével egyszerűbben megérthető, és kipróbálható a Windows új képességeinek már elkészült része.

A Microsoft 2003 novemberében, a Professional Developers Conference (PDC) alkalmával tette elérhetővé legújabb operációs rendszerének szoftverfejlesztők számára készített előzetes változatát. A Longhorn kódnéven futó rendszer a korábbi Windows verziók hibajavításain és a használhatóság növelésén kívül további innovatív megoldásokkal bővül.

A Longhorn PDC kiadásából ízelítőt kaphatunk abból, hogy miként változik meg az operációs rendszer felépítése, és milyen módszerek állnak a fejlesztők rendelkezésére ahhoz, hogy új szoftvereket készítsenek, vagy meglévő alkalmazásaikat képessé tegyék az új Windows-funkciók használatára. A jelenleg elérhető változat még nem béta, és nem is alpha verzió, hanem egy idejekorán kiadott, kizárólag fejlesztők, és egyéb informatikai szakemberek számára készített szoftver, aminek segítségével egyszerűbben megérthető, és kipróbálható a Windows új képességeinek már elkészült része.

A májusi WinHEC rendezvényen jelentik be a Longhorn várható hardverigényét, és könnyen elképzelhető, hogy a Longhorn lesz az első olyan operációs rendszer, amely DirectX-et hardverből támogató grafikuskártyát fog igényelni. A Microsoft szintén a WinHEC-re ígéri a Longhorn alpha verzióját, amely a vállalat állításai szerint lényegesen gyorsabb és stabilabb lesz, mint a most elérhető kiadás.


A Longhorn felülete

A végleges verzió megjelenésének időpontja továbbra is kérdéses, mivel a Windows XP SP2 és a Windows Server 2003 SP1 előkészületeinek felgyorsításához a vállalat átcsoportosította a Longhornon dolgozó fejlesztők egy jelentős részét. A spekulációk és a vállalat közleményei alapján a megjelenés 2006-ban, vagy még annál is később várható. Ez a csúszás az eredménye annak, hogy a Microsoft elsődleges célja a jelenleg üzemben lévő operációsrendszerek biztonságosságának javítása. A szervízcsomagok fejlesztése a megjelenési dátum eltolásán kívül azt is maga után vonja, hogy a boltokba kerülő Longhorn várhatóan kevesebbet fog tudni, mint amit a Microsoft eredetileg szeretett volna.

A szoftver telepítés után 180 napig használható. Ez a limit a tesztverziók esetében szokásosnak mondható, és mivel a fél év letelte előtt elérhetővé válik a tényleges alpha verzió, ez komoly gondot nem okoz.

[oldal:Avalon, prezentációs réteg]

Az Avalon kódnévre hallgató réteg felelős a Windows valamennyi megjelenítéssel és médiával kapcsolatos funkciójáért. Ezek a technológiák szükségesek a felhasználók és a számítógép közötti kommunikáció megteremtéséhez. Tervezésekor a legfontosabb célkitűzések között a felület- és a komponensprogramozás megkönnyítése, valamint a felhasználói élmény növelése szerepelt.

A felhasználói felület kirajzolása DirectX segítségével történik, ezáltal a rendszer kihasználja a modern grafikus kártyák valamennyi hardveres gyorsítófunkcióját. Az alkalmazások ClearType betűket jelenítenek meg, amit a Longhorn nem pixelenként renderel, hanem egy sokkal részletesebb képet készít el az adott betűről, és ezt rajzolja ki a képernyő felbontásától és a beállított színmélységtől függő élsimítással. A hardveres gyorsításnak köszönhetően az alkalmazások könnyebben animálhatóak, és akár futó videókat is beállíthatunk egy gomb vagy ablak hátterének, ami utána három dimenzióban mozgatható, transzformálható.


Az új Explorer

A nagyobb biztonság elérésre érdekében az operációs rendszer részeként megjelent a Trust Manager, ami egységes felületen tájékoztatja a felhasználókat a futó programok biztonság szempontjából kritikus műveleteiről. A felhasználók az alkalmazások futása előtt beállíthatják, hogy milyen jogosultságokat adnak a kódnak, ennek eldöntésében szöveges segítség is rendelkezésükre áll.

A Longhornban fontos célkitűzés, hogy minden alkalmazás által küldött üzenet és kirajzolt ablak egységes módon, egy helyen jelenjen meg, hogy a felhasználónak ne okozzon gondot az értesítések nyomon követése, és képes legyen rájuk az általa kiválasztott sorrendben reagálni. Ennek egyik eszköze a Sidebar névre hallgató panel, ami alapbeállítások mellett a képernyő jobb oldalán látható, és egy órát, valamint a Quick Launch Bart tartalmazza. A Sidebar képes tetszőleges tartalom megjelenítésére, de ehhez előre elkészített modulokra van szükség, csakúgy, mint a unixos Gnome panelének.

A Sidebaron megjeleníthető a rendszer tálcája is, ahonnan a Windows korábbi verzióiban a legtöbb értesítés érkezett. A Longhorn jelenlegi verziójában a Sidebaron elérhető továbbá a Synchronization menü -- ami számítógépek és más adattárolásra alkalmas eszközök fájljainak összehangolására szolgál -- és egy Slideshow modul, ami az általunk beállított képeket mutatja meg meghatározott sorrendben.


A Longhorn szinkronizációs eszköze

Az Avalon képes a beszéd felismerésére és szintézisére. Az alkalmazásokat könnyen fel lehet ruházni ezekkel a funkciókkal, ezért várható, hogy a jövő programjainak többsége már élőszóban kiadott parancsokat is meg fog érteni.

A Longhorn felületének alaptémája Slate névre hallgat, és nagyban hasonlít a Windows XP témájához, szinte csak sötétszürke színeivel tér el tőle. Természetesen a felületet a Windows XP és a korábbi Windows változatok szín- és formavilágára is vissza lehet állítani, azonban a Longhorn jelenleg elérhető változatában nincs semmilyen lehetőség a Sidebar és a Taskbar kinézetének megváltoztatására.

Az Avalon már támogatja a jövő nagyfelbontású monitorait is, amik a Microsoft szerint a következő évek során fognak elterjedni. Ezzel együtt érdemes megjegyezni, hogy a Longhorn olyan hardverekhez készül, amelyek 2006-ban már elterjedtnek fognak számítani, ezért tényleges hardverkövetelményeit megfelelő előrelátással lehet csak megjósolni. A hardverkövetelmények hivatalos bejelentése május elején, a WinHEC-en várható, de mivel a megjelenés időpontja még meglehetősen bizonytalan, és a végleges termék semmiképpen sem várható másfél-két éven belül, ezért fel kell készülni arra, hogy a Microsoft bejelentése is csak óvatos becsléseket tartalmaz majd.

[oldal:Az Avalon programozása 1.]

A Longhornra írt szoftverek felületének kialakítására lényegesen egyszerűbb lehetőségek állnak rendelkezésre, mint a korábbi Windows verziók esetében. Az egyik legérdekesebb újdonság, hogy a böngésző-alapú és a statikus, ablakszerű felületek létrehozására egységes megoldás alkalmazható, vagyis a két megközelítés fejlesztése között nincs jelentős különbség. Az Avalon az alkalmazások felületét dokumentumoknak tekinti, amire tetszőleges grafika vagy szöveg vihető fel.

A Windowsban megszokott, fixméretű ablakos megjelenítési modellhez leginkább a Fixed-format dokumentumok hasonlatosak, amik egy vászon-objektummal (Canvas) biztosítják az ablak tartalmának megrajzolását. A másik formátum, a Flow-format folyószöveg, illetve szabadon formázható tartalmak esetében használható. Előnye, hogy a HTML-hez hasonlóan az ablak méretétől, és a felhasználó beállításaitól függően teljesen dinamikusan épül fel az oldal. Az Adaptive flow-format dokumentumok olyan további funkciókat adnak a fejlesztők és felülettervezők kezébe, amivel legtöbb esetben biztosítható a dokumentum arányainak pontos megjelenítése, függetlenül a felhasználók és az operációs rendszer beállításaitól. Az adaptív módszer elsődleges célja, hogy a felhasználók számára kényelmesen olvasható oldalakat hozzon létre, másodsorban pedig szigorúan megőrizze azt a formát, amit a designerek létrehoztak.

Az Avalon alkalmazások felülete XAML fájlok segítségével kerül meghatározásra. Ezek az XML állományok egy olyan sémá alapján jönnek létre, ami kifejezetten szoftverfelületek komponenseinek meghatározására készült. Az XML-alapú tárolás és feldolgozás ésszerű lépésnek tekinthető, mivel az alkalmazások felületén megtalálható gombok és egyéb vizuális komponensek logikai fát alkotnak, ahol a komponensek egymáshoz képesti viszonya a szülő-gyerek-testvér kapcsolattal tökéletesen modellezhető. Az XML formátum, illetve az annak feldolgozásához használható XML DOM (Document Object Model) lehetőséget ad arra, hogy bármely komponensből (a fa egy eleméből) bármely másik komponenst el lehessen érni, méghozzá anélkül, hogy bármit tudnunk kéne annak típusáról. Két komponens viszonya a következőképpen alakulhat (a kiindulási elemtől viszonyítunk):

  • Felmenő (ős): valamennyi elem, ami az adott komponenst tartalmazza
  • Leszármazott: a komponens által tartalmazott elemek, illetve a tartalmazott elemek által tartalmazott további elemek
  • Szülő: a komponenstől számított legközelebbi felmenő; ez az elem tartalmazza közvetlenül a kérdéses komponenst
  • Gyerek: a kérdéses komponens által tartalmazott közvetlen leszármazottak
  • Testvér: ha a két kérdéses komponens szülője ugyanaz az elem, akkor ők testvérek (egy szülőtől származnak)

Példa: egy ablak menüjének lehetnek menüpontjai, és egyes menüpontjainak lehetnek további menüpontjai. Ebben az esetben a menünek minden menüpont leszármazottja, és a menüből közvetlenül kiválasztható menüpontok pedig a gyerekei. A menü szülője az az ablak, amelyről a menü elérhető. Az egy szinten lévő menüpontok egymás testvérei, és egy menüpont további menüpontjai az eredeti menüpont gyerekeinek számítanak.


A Longhornban található Outlook Express

Az XML fában meglehetősen egyszerű a navigálás, akár az elemek metódusai és paramétereinek használatával, akár magasszintű, a fában található elemek keresésére és kiválasztására alkalmas nyelvek segítségével, mint amilyen például az XPath és az XQuery.

Ez természetesen nem jelenti azt, hogy eltűnnek a fejlesztőeszközök ablaktervező lehetőségei. Mindössze arról van szó, hogy a programok felületének nem kell részét képeznie a leforgatott forráskódnak, és az így létrejött bináris állománynak, hanem a program módosítása nélkül, egyedül az XAML fájl átírásával finomítható a felhasználói felület. Ezzel a szoftverek lokalizációja és a globalizációja könnyebbé válik, valamint jobban elkülönül a felülettervezés és a programozás feladatköre, mivel így a designerek fejlesztői ismeretek nélkül is meg tudják tervezni az alkalmazások felületét, méghozzá úgy, hogy ahhoz a fejlesztőknek már hozzá se kell nyúlniuk. Az elkészült XAML dokumentumokat digitális aláírással is el lehet látni, amivel biztosítható eredetisége és érintetlensége.

A Longhorn beépítve tartalmaz egy Windows Client Printer Driver nevezetű virtuális nyomtatót, amellyel bármely programból XAML fájlba menthető a nyomtatandó dokumentum. Ez a funkció csak fix méretű (Fixed-format) XAML dokumentumok létrehozására használható.

Az operációs rendszer összes szöveggel kapcsolatos funkciója Unicode alapú, és támogatja a világ összes írott nyelvét, karakterkészletét. A Longhorn - elődeihez hasonlóan - nem támogatja sem az Adobe Type 1, sem az OpenType-CFF betűtípusokat, azonban lehetőséget nyújt a Microsoft OpenType betűkészletek használatára. Az Avalonon keresztül kirajzolt vagy szerkesztett szövegek szóköze, betűköze és sortávolsága automatikusan, a lehető legideálisabb módon kerül meghatározásra; ezzel komoly terhet vettek le azon fejlesztők válláról, akiknek egzotikus nyelvekre is fel kell készíteniük alkalmazásaikat. Az Avalon támogatja a szóelválasztást a felhasználói felületen, ezért az automatikus sortörések után is sokkal olvashatóbb oldalakat kapunk.

[oldal:Az Avalon programozása 2.]

Gyakori probléma a meglévő Windows alkalmazásoknál, hogy nehéz a különféle funkciók között kapcsolatot találni, vagyis a legtöbb esetben, ha a felhasználó egy több parancsból álló tevékenységet szeretne elérni, egyenként kell megtalálnia az ehhez szükséges menüpontokat, vagy gombokat. A Longhornban az összetartozó funkciók a legegyszerűbben hiperlinkek segítségével köthetőek össze, míg a komplexebb feladatok kivitelezésének módja könnyedén leírható az új súgórendszeren keresztül.

Míg korábban a súgó összes oldalát a dokumentáció szerkesztőjének kellett megterveznie és legyártania, addig a Longhorn rendelkezésre bocsátja saját súgójának leggyakrabban használt oldaltípusait, hogy a lehető legkevesebb munkával és leginkább a tartalomra koncentrálva lehessen súgókat létrehozni. Az így kapott súgó előnyére szolgál továbbá, hogy a felhasználók minden alkalmazáshoz ugyanazt a segítségnyújtási felületet kapják, amit ha egyszer kiismertek, attól kezdve gond nélkül tudnak használni.


A Longhorn súgója

Jelenleg ugyancsak komoly fejfájást okoz a fejlesztőknek a különféle ablakok közötti vezérlésátadás, illetve maguknak az ablakoknak a megjelenítése. A Stuctured Navigation Framework (SNF) ezekre a problémákra nyújt megoldást. Az SNF működéséhez minden megjelenítendő komponenshez egy oldal-objektumot kell létrehozni. Ezek az objektumok több konstruktorral is rendelkezhetnek, aminek segítségével tetszőleges adatok juttathatóak el egyik oldalról vagy ablakról a másikra.

Az SNF naplózza a vezérlésátadás folyamatát, és amennyiben az aktuális oldal befejezte a tevékenységét, és ezt jelzi a rendszer felé, akkor a naplóban szereplő utolsó objektumra kerül vissza a vezérlés, ahol szintén lehetőség van kimeneti paraméterek átadására. Ez a koncepció leginkább az eljáráshívások stack-jére hasonlít. A navigációban résztvevő objektumoknak nem kötelező vizuális komponensekre, vagy ablakokra hivatkozniuk. A nem látható oldal-objektumok vezérlési csomópontként használhatóak. Az SNF segítségével valamennyi vezérlési topológia megvalósítható, és a vezérlésátadás folyamata futásidőben, dinamikusan is módosítható.

A komponensprogramozók fellélegezhetnek, mivel a Longhorn olyan képességekkel rendelkezik, amik a korábbi komponensfejlesztői munka több mint felét feleslegessé teszik. Hozzá kell tenni, hogy ezeknek a képességeknek egy jelentős része már a .Net keretrendszer részeként régebb óta elérhető, ugyanakkor az Avalon további funkciókkal bővíti a meglévő platformot.

Az egyik legfontosabb előrelépés, hogy a grafikus alrendszer -- beleértve az ablakokat és a vizuális komponenseket is -- a gyökeréig újra lett írva .Net-alapúra. A keretrendszer korábbi verziói csak egy könnyen használható felületet nyújtottak a korábbi Win32 API helyett, de ettől függetlenül Longhorn előtti operációs rendszerek még mindig az ősöreg ablakok közötti üzenetküldéssel, és DC-re (Device Context) rajzolással működnek. Az Avalon a korábbi Win32 objektumok helyett strukturált .Net osztályokat kínál a felület elemeinek kezelésére, és ő maga is ezek segítségével működik.

A másik jelentős újítás a Windows komponenseinek teljeskörű újrahasznosításának lehetősége. Az új koncepció szerint minden komponens kiajánl megadott viselkedésosztályokat (Control Pattern), amiket bárki megvalósíthat. Egy komponens viselkedésosztályai között lehetnek kötelezően és opcionálisan megvalósíthatóak is, valamint olyanok, amiket a komponens csak bizonyos feltételek teljesülése esetén használ fel. Például egy ListBox komponensnek kötelezően meg kell valósítani az elemkijelöléssel kapcsolatos funkcióit, azonban a görgetést csak abban az esetben, ha a listában több elem található, mint amennyi a lista által egyidejűleg megjeleníthető. Ez a megközelítés olyan, mintha a komponens különféle interfészeket kínálna programozásához, azonban öröklődés szempontjából lényegesen előnyösebben használható, mintha egyszerűen megvalósítanánk a kiajánlott interfészeket, mivel teljesen különválasztható a komponensek saját, valamint viselkedésosztályainak öröklődése.

A felhasználó által kezdeményezett beavatkozásokról -- mint amilyen például az egérmozgatás, vagy billentyűleütés --szintén .Net objektumok értesülnek. A szerkesztéssel kapcsolatos szolgáltatások és viselkedésosztályok (Edit Services, Edit Behaviors) a felület logikai fájának bármelyik eleméhez csatlakoztathatóak, amitől annak az elemnek valamennyi leszármazottja rendelkezni fog a kérdéses szolgáltatással, kivéve, ha egy adott szinten deaktiváljuk azt. A rendelkezésre álló szolgáltatások között megtalálható a kijelölés, az undo-redo, a drag-drop, valamint az általános billentyű-, és egérkezelés.

A .Net keretrendszer támogatja a GDI+ technológiát, ami a korábbi GDI interfész továbbfejlesztett változata. A GDI vagy a GDI+ szükséges ahhoz, hogy az operációs rendszeren keresztül rajzolni lehessen a képernyőre. Az GDI+ elődével szemben képes gradiensek kirajzolására, transzformációs mátrixok segítségével tetszőleges képmanipulációt végezni, áttetsző felületeket kezelni, és rugalmasan megadható képterületekkel dolgozni. Mindemellett támogatja a BMP, GIF, JPEG, EXIF, PNG, TIFF, ICON, WMF, EMF formátumok operációs rendszerben történő felhasználását.

Az Avalon MediaServices API-ja felelős a különféle médiák megjelenítéséért és kezeléséért. Egységes felületet nyújt valamennyi médiatípus feldolgozására, amik között megtalálhatóak az audió, videó, bináris, HTML, kép, és script állományok is. Minden lejátszás, vagy megjelenítés esetén meg lehet határozni a forrást (ami lehet egy vagy több fájlnév, vagy stream), a szükséges transzformációkat, és a renderelés célpontját, vagy célpontjait. A hangerő változtatásához és a hangkártya keverőjének használatához sincs többé szükség Win32 API hívásokra, helyette segítőkész .Net objektumok állnak rendelkezésre.

CD-k lejátszásra megjelent a CD:// namespace, amivel akár programkódból, akár az Explorerből egyszerűen lehet audio CD-k megadott számait lejátszani. Például a "CD://E/2-4" parancs lejátssza az E meghajtóban található lemez második, harmadik és negyedik számát.

Az Avalon részét képezi a Natural Language Services nevezetű szolgáltatás is, ami képes értelmezni az általunk megadott szöveget az adott nyelv szabályai és szókincse alapján. Ez a technológia még gyerekcipőben jár, jelenleg mondatok szavainak elemzésére és szétbontására alkalmazható, a tényleges értelmezéshez szükséges funkciók még nincsenek készen.

A Longhorn szinte összes állományát le lehet védeni a Rights Management technológia felhasználásával, ami garantálja, hogy csak azok a felhasználók férhetnek hozzá a kérdéses fájlokhoz, akiknek a fájl tulajdonosa erre engedélyt adott. Ez a védelem független a fájlrendszer jogosultságaitól; itt a jogosultság magában a fájlban, vagy egy konténerobjektumban kerül meghatározásra. A megnyitáshoz érvényes kulcsra, vagy tanúsítványra van szükség.

[oldal:WinFS, adattárolás]

A WinFS az új operációs rendszer adattárolási megoldásait foglalja magában. A Longhorn adattárolási képességei egyesítik a relációs adatbázisok és az NTFS fájlrendszer képességeit, ezáltal a fájlok szervezése, keresése és megosztása lényegesen egyszerűbbé válik.

A WinFS a fájlok és az adatok kapcsolatait gráfként tárolja el, aminek köszönhetően a fájlrendszer valamennyi eleme kapcsolatban állhat az összes többi állománnyal. Míg korábban egy fájl egyszerre csak egy könyvtárban lehetett megtalálható, addig a WinFS többféle csoportosítás szerint is képes a kérdéses állomány tárolására. A Longhorn minden elemhez hozzárendeli annak alaptulajdonságait, típusinformációját, valamint az elem típusától függően akár további adatokat is. Ha például a kérdéses fájl egy kép, a WinFS annak formátumát, méreteit és színmélységét is tárolja, és lehetőséget ad arra, hogy ezek segítségével később megtaláljuk azt. A felhasználók saját kategóriákat is létrehozhatnak, és ezekhez bármely fájlt hozzárendelhetik.

A fájlrendszer az adatok megváltozásakor, illetve adott kritériumok teljesülésekor képes üzeneteket küldeni a Microsoft SQL Serverben is megtalálható Notification Services segítségével. Ezek az üzenetek a rendszer Routing képességének kihasználásával kézi eszközökre is továbbküldhetőek, vagy akár MSN üzenet formájában is érkezhet hír az eseményről. A WinFS-ben található adatokat betűjelek segítségével nem lehet elérni, helyette UNC (Universal Naming Convention) elérési utat kell megadni. Ez pontosan úgy működik, mint a hálózati megosztások elérése a korábbi Windows változatokban.


Üzenettovábbítási kritériumok beállítása

Egy NTFS fájlrendszer tetszőleges számú WinFS tárhelyet, úgynevezett Store-t tartalmazhat. A Longhorn telepítésekor alapból rendelkezésre álló WinFS tárhely a DefaultStore, a Catalog Store pedig a rendszeren megtalálható összes WinFS tárhely metaadatait tartalmazza. Ennek segítségével állapíthatóak meg a különféle WinFS adatbázisok tulajdonságai, és az elérésükhöz szükséges paraméterek. A tárhelyek könyvtárait a FAT és az NTFS fájlrendszerhez hasonlatosan meg lehet osztani, ezáltal a hálózaton keresztül mások is elérhetik azokat.

A WinFS lehetőséget biztosít automatikus biztonsági mentések készítésére, valamint különféle tárhelyek közötti adatszinkronizációra, akár hálózaton keresztül is. A WinFS jogosultságrendszere szinte minden szempontból megfelel az NTFS által felállított szabványnak, egyedüli különbség a linkek kapcsán adódik, ugyanis a WinFS-ben egy állomány jogosultsága ténylegesen a fájlrendszerben betöltött helyétől függ és a szülők jogosultságai alapján kerül meghatározásra.


A Longhorn megosztásai

Míg az NTFS minden fájlt bájtok sorozataként tárolt, a WinFS állományok két részből tevődnek össze: az első a metaadat, ami a fájllal kapcsolatos kereséshez és feldolgozáshoz szükséges információkat tartalmazza, a másik pedig maga az adatfolyam, ami hagyományos NTFS állományként viselkedik. A Longhorn rendszerfájljai továbbra is kizárólag az NTFS fájlrendszerben találhatóak meg, ezeket nem lehet a WinFS tárhelyekbe áthelyezni. A WinFS tárhelyek állományai a Win32 fájlkezelő eljárások használatával is elérhetőek, de ilyenkor a hozzárendelt tulajdonságok kiolvasására és módosítására nincs mód.

A WinFS képes ACID tranzakciók kezelésére. Az ACID tranzakciók a következő viselkedést garantálják:

  • Atomicity (bonthatatlanság): minden tranzakció vagy hibátlanul sikerül, vagy nem. Amennyiben a tranzakció egyetlen részfeladata is hibával tér vissza, a teljes tranzakció hibásnak minősül.
  • Consistency (konzisztencia): garantálja, hogy a tranzakció sikertelensége esetén az eredeti, vagyis a tranzakció megkezdése előtti állapotok állnak helyre. Egy tranzakció futása során több folyamat is módosíthatja ugyanazokat az adatokat, ezért precízen naplózni kell az adott tranzakció által létrehozott módosításokat.
  • Isolation (elszigetelés): célja, hogy a párhuzamos tranzakciók csak a kérdéses tranzakciók befejezése után láthassák a másik tranzakció által módosított adatokat.
  • Durability (hibatűrés): a rendszer minden esetben létfontosságú célnak tekinti az adatok hibátlan megőrzését. A tranzakciók során módosított adatok eredeti állapota folyamatosan rendelkezésre áll, ezért rendszerhiba esetén az adatok nem vesznek el.

Az ACID tranzakciók segítségével könnyebben lehet ugyanazt a fájlt többféle tevékenységhez párhuzamosan használni, de fokozottan oda kell figyelni a megfelelő izolációs szint megadásához.

A WinFS programozására COM interfészeken és .Net osztályokon keresztül is lehetőség nyílik. Mindkettő képes az OPath nyelv használatára, amivel könnyedén megtalálhatóak az adott feltételeknek megfelelő állományok. A WinFS fájlok megnyitásakor az objektumok polimorfizmusának kihasználásával nemcsak fájlszintű adatok, hanem formátum-specifikus információk birtokába is könnyedén juthatnak a Longhorn alá fejlesztett alkalmazások.

Az adatok relációs elérésére egyedül az OLE DB adatbázis-interfész alkalmas, de azon keresztül a WinFS kapcsolatok és állományok ugyanúgy kezelhetőek, mint bármely adatbázisban található tábla vagy sor, és SQL lekérdezések is lefuttathatóak rajtuk. A rendszer a lekérdezések eredményét XML formátumban is visszaadhatja, valamint a kapcsolati gráfok, és az elemek XML szerializáció segítségével is tárolhatóak.

[oldal:Indigo, alkalmazásközi kommunikáció]

Az Indigo a Longhorn kommunikációs alrendszere, amely az 1.1-es .Net keretrendszer által lefektetett technológiákon kívül a legfrissebb irányelveknek megfelelően a SOA (Service Oriented Architecture) koncepciót is támogatja. A Longhorn általános nagyvállalati, és integráció-centrikus megoldások fejlesztéséhez az Indigo Szolgáltatásokat ajánlja, amely a World Wide Web Consortium SOAP 1.2 specifikációjára épül. Az ezzel készített szoftverek könnyen skálázhatóak, rugalmasan továbbfejleszthetőek és integrálhatóak.

A korábbi alkalmazások legnagyobb hátránya az volt, hogy a kommunikációban résztvevő valamennyi szoftvernek pontosan ismernie kellett a meghívandó eljárások paramétereit, elérhetőségét, és működésének részleteit. Szélsőséges esetekben egyedi kommunikációs protokollok programozására is szükség volt, hogy a meglévő, nem kifejezetten bővíthető és integrálható alkalmazások is képesek legyenek új funkcionalitás elérésére az újonnan kifejlesztett szoftvermodulokból.


A DxDiag Longhornon

A kommunikációs modellek fejlődése az összes nagyobb szoftverfejlesztő vállalatnál azonos irányban, és közel egyforma tempóban haladt, ennek első állomásának a középréteg megjelenés tekinthető. Eleinte a leghatékonyabbnak az ORB (Object Request Broker) megoldások bizonyultak, -- mint például az OMG által fejlesztett CORBA technológia -- valamint a Microsoft interfész-központú COM (Component Object Model), majd a Windows 2000-ben debütáló COM+ architektúrája. Mindről elmondható, hogy erősen típusos interfészek használatával tették lehetővé alkalmazások kommunikációját, és működéséhez az egymással összekapcsolt szoftvereknek egyenként rendelkezniük kellett az interfészek leírásával. Ez az alkalmazások nehézkés bővíthetőségével járt együtt, ugyanakkor a megközelítés már messze meghaladta a korábbi, egyedi alapon kivitelezett kliens-szerver kommunikációs megoldások lehetőségeit.

A következő mérföldkőnek az üzenet-alapú kommunikáció bizonyult, aminek legjelentősebb képviselői az IBM MQSeries és a Microsoft MSMQ voltak. Az üzenet-alapú kommunikáció szakított az előre rögzített interfészek koncepciójával, helyette hibatűrő, tranzakció-kezeléssel ellátott, rugalmas csatornákat biztosított tetszőleges üzenetek szállítására. Ezeknél a technológiáknál az üzenetek küldése és fogadása a hálózati protokollokhoz hasonló elven működik, amit QoS (Quality of Service) képességek tesznek még hasznosabbá, könnyen skálázhatóvá. Független a hálózat megbízhatatlanságától, mivel nem igényel folyamatos kapcsolatot a kommunikációban résztvevő alkalmazások között, és a hibákat lehetőségeihez képest elhárítja.

A jelenleg legáltalánosabban támogatott megoldások web-alapú szolgáltatásokra (WebService) épülnek. Talán ez az eddigi legrugalmasabb architektúra, mivel nincs megkötve sem a kommunikációs protokoll, sem az üzenetek konkrét formátuma, vagyis akár HTTP, akár TCP segítségével felépíthető az alkalmazásközi kapcsolat. Az üzenetek az esetek nagy többségében SOAP formátumban kerülnek meghatározásra. Minden WebService a külvilág számára szabványos felület segítségével ajánlja ki képességeit, ezáltal bármely másik komponens szabadon felhasználhatja azokat, amennyiben támogat legalább egyet az elterjedt kommunikációs protokollok közül.

Érdekes mellékvágány a Remoting, ami első ránézésre rugalmasnak és strapabírónak tűnik, azonban komolyabb rendszerek fejlesztésekor szép lassan bukkannak elő problémái. Alapötlete, hogy a kliensoldalról a szerver tudása objektumokon keresztül érhető el, amik a programozó számára úgy viselkednek, mintha valódi kliensoldali példányok lennének. Igazából az ilyen objektumok eljárásainak hívásakor a keretrendszerek proxy osztályokon keresztül automatikusan elvégzik a hálózati kommunikációhoz szükséges valamennyi feladatot, és ebbe a programozónak legfeljebb finomhangolás és teljesítménynövelés céljából kell beleszólnia.

Ez a megoldás kényelmesen használható a kliensoldalon, és a legtöbb esetben nem igényli, hogy a programozó releváns hálózati fejlesztési tapasztalat birtokában legyen; elegendő hozzá az objektum-orientált programozás alapos ismerete. Hátránya, hogy az esetleges hibák felderítése hatalmas feladatot jelent, és az igazán hatékony használatához a rendelkezésre álló Remoting megvalósítások manuális bővítése is szükséges lehet. Ugyancsak negatívum, hogy a kommunikáció kizárólag kapcsolat-alapú protokollok használatával lehetséges, ami szinte lehetetlenné tette hibatűrő rendszerek kialakítását, és a rendszer bővítése általában az összes komponens újrafordításával jár. Remoting megoldással a Java és a .Net keretrendszerben is találkozhatunk, a Javában az RMI (Remote Method Invocation), .Net alatt pedig a .Net Remoting technológia képében.

Az Indigo képes XML WebService, .Net Remoting, .Net Messaging (korábbi nevén MSMQ) és szolgáltatás-alapú kommunikációs modellek kialakítására is. Igazi újdonságot csak az Indigo Szolgáltatások nyújtanak, a többi technológia közel változatlan formában a .Net keretrendszer 1.1-es verziójában is elérhető.


A jogosultság hiánya még a lokális adminisztrátornak is gondokat okoz

Az Indigo Szolgáltatások a meglévő architektúrák pozitív tulajdonságait foglalják magukban: egyesíti a Remoting lokális objektumkoncepcióját, a Messaging alrendszer hibatűrését és tranzakció-kezelését, valamint a WebService-ek könnyű integrálhatóságát és bővíthetőségét. Minden Indigo Szolgáltatás öt réteg felhasználásával jöhet létre (a felsorolás a legmagasabb szintű rétegtől a legalacsonyabb szintűig halad):

  • Szolgáltatások (Services): Ez a réteg tartalmazza az alkalmazások többsége által elérhető szolgáltatásokat, funkciócsoportokat, a legmagasabb absztrakciós szinten definiálva.
  • Típusos csatornák (Typed channels): Ebben a rétegben kerülnek meghatározásra a szolgáltatásból elérhető, meghívható eljárások, metódusok. Itt szabályozható, hogy az alacsonyabb szinten található üzenetek mely metódusokhoz jussanak el.
  • Típus nélküli csatornák (Untyped channels): Egy adott Porttal együttműködve képesek megadott sémák szerinti üzenetek küldésére és fogadására.
  • Portok (Ports): A típus nélküli csatornákról érkező üzenetek útjának és sorrendjének szervezésével foglalkozó réteg.
  • Adatszállítási technológiák (Transports): Ez a réteg felelős a tényleges alkalmazásközi kommunikációért, itt történik meg az üzenetek kiküldése, fogadása, valamint a kívánt formátumokba történő konverziója és szerializációja.

[oldal:Összefoglalás]

A Longhorn legnagyobb előnye a programozók számára, hogy a korábbi Windows verziókhoz képest sokkal átgondoltabb a felépítése, és el lehet felejteni a régi, nehézkés Windows API-k használatát. A Longhorn valamennyi funkcionalitása .Net osztályokon keresztül érhető el, aminek köszönhetően a fejlesztési feladatok gyorsabban, és egységesebb módszerekkel végezhetőek el.

Ugyanakkor a Longhorn PDC verziójának sebessége katasztrofális, Virtual PC-re, VMware-re és PC-re telepítve egyaránt. Ennek oka valószínűleg a Kernel egyes részeivel, vagy az ahhoz kapcsolódó modulok kiforratlanságával függ össze, mert a Kernel a processzort üresjáraton is minimum 20-25 százalékosan terheli a teszteléshez használt Athlon XP 1700+ processzoron. A májusi Longhorn verzió remélhetőleg jelentős gyorsulást eredményez, mert ilyen állapotok mellett nem sok fejlesztő fogja használni a rendszert a termék megjelenésig, és ugyancsak kevés olyan bétateszter akad majd, aki hajlandó lesz 10 percet eltölteni egy Explorer ablak megnyitásával.


Brutális processzorterhelés a kernel szintjén

A felület, és az alkalmazások még egyáltalán nem kiforrottak, ezért azok, akik mindennapi munkára használnák a rendszert, gyorsan tegyenek le róla. Van néhány meglepő jelenség a Longhorn működésében, ami elsőre furcsának tűnhet, de ezek az operációs rendszer korai állapotára tekintettel nem mérvadóak. Például a DxDiag Windows XP Professionalnak hiszi a gépet, és még egy lokális adminisztrátornak sincs jogosultsága az Internet Connection Sharing és a tűzfal beállításait megváltoztatni.

Amennyiben a hivatalos alpha verzió sem hoz jelentős gyorsulást, akkor várhatóan a jelenlegi csúcsgépeknél is magasabb hardverkövetelményekkel fog előállni a Microsoft, arra hivatkozva, hogy 2006-ban, vagy utána azok már átlagosnak fognak számítani. Ebben minden tekintetben igazuk is lesz, de egy operációs rendszer programozhatóságának egyszerűsítése és az új funkcionalitás megjenelése nem járhat a meglévő képességek ilyen mértékű sebességcsökkenésével.

Szólj hozzá a fórumban!

Nagyon széles az a skála, amin az állásinterjú visszajelzések tartalmi minősége mozog: túl rövid, túl hosszú, semmitmondó, értelmetlen vagy semmi. A friss heti kraftie hírlevélben ezt jártuk körül. Ha tetszett a cikk, iratkozz fel, és minden héten elküldjük emailben a legfrissebbet!

a címlapról