Pojďte s námi programovat !

Architektonická struktura vývojově-exekuční platformy Microsoft .NET Framework 3.5
Microsoft .NET Framework 3.5 je vývojově-exekuční platforma, což znamená, že poskytuje jednak množinu softwarových nástrojů, programovacích jazyků a spřízněných technologií pro vývoj počítačových aplikací nové generace, a rovněž běhové prostředí, jež formuje ekosystém, v němž dochází k exekuci řízených aplikací .NET. Platforma .NET Framework 3.5 je založena na následujících základních komponentách:

Virtuální exekuční systém (VES). Virtuální exekuční systém je softwarový stroj, v němž běží aplikace .NET, které byly připraveny v jazyce C# 3.0, případně v jakémkoliv jiném .NET-kompatibilním programovacím jazyce. VES představuje výkonný modul, který nabízí aplikacím .NET všechny nízkoúrovňové služby, jež jsou spojeny s jednotlivými etapami jejich životních cyklů. Jádrem virtuálního exekučního systému je společné běhové prostředí CLR (Common Language Runtime). Prostředí CLR uskutečňuje následující manipulační operace:

Just-In-Time kompilace MSIL kódu do podoby nativních x86 strojových instrukcí.
Alokace a dealokace paměťových bloků.
Garance typové bezpečnosti.
Správa aplikačních domén a programových vláken.
Automatická kontrola životních cyklů vytvořených softwarových objektů.
Zabezpečení jazykové a platformové interoperability.

Bázová knihovna tříd FCL (Framework Class Library). Počítačoví vědci společnosti Microsoft připravili pro vývojáře znamenitou knihovnu obsahující více než deset tisíc různorodých datových typů. K zapracovaným datovým typům patří třídy, struktury, enumerace, rozhraní, delegáti a další entity. Všechny zmí­-
něné substance umožňují dosáhnout vyšší úrovně automatizace softwarových činností. Bázová knihovna tříd je proto studnicí vysoce kvalitních, otestovaných a optimalizovaných datových typů, jejichž funkcionalitu mohou okamžitě upotřebit miliony vývojářů, kteří se nemusí zabývat jejich vytvářením.

Společný typový systém CTS (Common Type System). Jednou z konkurenčních výhod platformy .NET Framework 3.5 je unifikovaný typový systém, jenž je sdílen všemi .NET-kompatibilními programovacími jazyky. Typová uniformita je ceněnou vlastností, poněvadž umožňuje naplno rozvinout ideu softwarové interoperability, tedy spolupráce mezi více programovacími jazyky. Poněvadž existuje sjednocený typový systém, jsou deklarované datové typy dosažitelné bez ohledu na použitý programovací jazyk. Je tedy zcela nepodstatné, zda se vývojář rozhodne psát svou aplikaci v jazyce C#, nebo sáhne po Visual Basicu či C++/CLI. Datové typy sdružené v společném typovém systému CTS jsou členěny do hierarchických jmenných prostorů, v nichž se nacházejí funkčně spřízněné entity.

Společná jazyková specifikace CLS (Common Language Specification). Společná jazyková specifikace determinuje množinu syntaktických a sémantických programových rysů, jimž musí vyhovovat veškeré .NET-kompatibilní programovací jazyky a jejich překladače (kompilátory). Specifikace CLS říká, že jisté programovací techniky jsou společné pro všechny programovací jazyky působící na platformě .NET Framework 3.5. Díky specifikaci CLS a společnému typovému systému CTS je možné, aby byla jedna aplikace .NET vytvářena ve více .NET-kompatibilních programovacích jazycích současně. Kupříkladu jádro aplikace může být napsáno v jazyce C# 3.0, zatímco externí dynamicky linkovaná knihovna (.dll) smí být připravena ve Visual Basicu 2008 nebo v C++/CLI. Díky CLS a CTS mohou obě součásti mezi sebou úzce spolupracovat a vést plnohodnotný informační dialog. Výborné je, že veškeré technické detaily nastíněné softwarové interoperability řeší za programátory společné běhové prostředí CLR platformy .NET Framework 3.5. To je veliká úleva, zejména když si vzpomeneme na dávné doby, kdy byla realizace všech datově-konverzních operací v kompetenci samotných vývojářů. Nemusíme snad dodávat, jak složité bylo tyto operace korektně provádět tak, aby žádní účastníci spolupráce netrpěli.
Základní stavební strukturu platformy .NET Framework 3.5 vidíte na obrázku.

Vidíme na něm vzájemný vztah mezi hardwarovou infrastrukturou počítače, operačními systémy třídy Microsoft Windows a vývojově-exekuční platformou .NET Framework 3.5. Platforma .NET 3.5 může být nainstalována pouze na systémech Windows společnosti Microsoft. Přímo podporovány jsou systémy Windows XP SP2 a Windows Vista. Ačkoliv existují projekty pro portování platformy .NET Framework 3.5 na jiné operační systémy (vzpomeňme třeba projekt Mono pro Linux a další systémy), prozatím ještě nemůžeme mluvit o multiplatformním charakteru této vývojově-exekuční platformy. Platforma .NET Framework 3.5 zavádí nová technologická aplikační programová rozhraní, která byla uvedena v souvislosti se systémem Windows Vista:

Windows Presentation Foundation (WPF),
Windows Communication Foundation (WCF),
Windows Workflow Foundation (WF),
Windows CardSpace (WCS).
Evoluce platformy Microsoft .NET Framework
Ačkoliv se v našem seriálu budeme pravidelně potkávat s nejnovější verzí vývojově-exekuční platformy Microsoft .NET Framework, považujeme za vhodné představit vám celou evoluci tohoto pozoruhodného softwarového ekosystému. Geneze a následující vývoj platformy je zobrazen na dalším obrázku.

První verze platformy .NET byla s velkou slávou uvedena v roce 2002. O několik měsíců později, v první polovině roku 2003, se k vývojářům dostalo vyhotovení 1.1 s minoritními aktualizacemi. O poznání větší inovace můžeme zaznamenat mezi verzemi 1.1 a 2.0, která se na světlo světa dostala koncem roku 2005. Platforma .NET 2.0 byla navzdory svému názvu již třetím vydáním softwarového universa, které přineslo podporu pro důmyslné zdokonalení v jazycích Visual Basic 2005, C# 2.0 a první uvedení zbrusu nového .NET-kompatibilního jazyka s názvem C++/CLI. Titul „největší softwarová inovace“ si ve verzi 2.0 odnesla podpora pro generické (parametrizované) programování, která byla pečlivě zapracována do všech nosných programovacích jazyků. V roce 2006, souběžně s představením operačního systému Windows Vista, vypustila společnost Microsoft na softwarový trh „novou“ verzi platformy s označením 3.0. Adjektivum není v předcházející větě umístěno do uvozovek náhodou: .NET 3.0 byl vyloženě marketingově zvolený název platformy, poněvadž programové jádro i nadále spočívalo na základech položených verzí 2.0. Jedinou viditelnou modifikací bylo začlenění již zmíněných rozhraní API pro Windows Vista (WPF, WCF, WF a WCS). Již ne marketingové, nýbrž kompletně vylepšené verze se platforma .NET dočkala koncem roku 2007. Prozatím nejnovější edice vývojově-exekuční platformy je identifikována pořadovým číslem 3.5.

Technický pohled na proces vytvoření aplikace .NET

Jak se vytváří a z čeho je složena jednoduchá aplikace .NET napsaná v jazyce C# 3.0, to jsme se naučili v předcházející části. Nyní bychom vám rádi nabídli tak trochu zákulisní pohled na všechny technické aspekty, jež se s procesem vytváření aplikací .NET pojí.
Programátor vytváří aplikaci tím, že zapisuje zdrojový kód algoritmů, jež řeší problémové úkoly a automatizují požadované činnosti. Zdrojový kód jazyka C# 3.0 je zapisován do editoru zdrojového kódu, což jsme si také již vyzkoušeli. Když máme zdrojový text programu napsaný, vydáme pokyn na přeložení aplikace. Ke slovu se dostane překladač (kompilátor), který provede lexikální, syntaktickou a sémantickou analýzu zapsaného zdrojového kódu. Během lexikální analýzy překladač zkoumá, zda je zdrojový kód složen z korektně zkonstruovaných lexikálních jednotek, přesně podle pravidel daných gramatikou programovacího jazyka. Pokud je vše v pořádku, překladač přechází na syntaktickou analýzu, jejímž cílem je zjištění, zda programátor při zadávání zdrojového textu programu užil správné syntaktické konstrukce a jejich kombinace. Nejtěžší ze všech tří analytických etap je sémantická analýza, protože v ní překladač musí determinovat smysl zdrojového kódu v konkrétní lexikálně-syntaktické formě. Pokud je verifikace sémantické stránky zdrojového kódu shledána jako bezproblémová, překladač podrobí kód optimalizačním algoritmům a nakonec jej převede na mezikód jazyka MSIL (Microsoft Intermediate Language).
MSIL je nízkoúrovňový pseudostrojový objektově orientovaný programovací jazyk, do jehož podoby jsou překládány zdrojové kódy všech .NET-kompatibilních programovacích jazyků vyšší úrovně. Někdy se jazyk MSIL označuje zkráceně pouze jako IL (Intermediate Language) nebo také CIL (Common Intermediate Language). Vzhledem k tomu, že platforma .NET Framework 3.5 garantuje typovou bezpečnost, jazykovou a platformovou interoperabilitu, je existence „mezijazyka“ MSIL nutná. Každý z překladačů jazyků C# 3.0, Visual Basic 2008 a C++/CLI umí generovat instrukce kódu jazyka MSIL přímo z programátorem zapsaného zdrojového kódu viz obrázek.
Vygenerovaný MSIL kód je uložen do řízeného modulu, jenž je posléze zařazen do sestavení aplikace .NET. Sestavení (anglicky assembly) je logickou jednotkou aplikace .NET, která vůči vnějšímu světu působí jako monolitní celek. Sestavení aplikace .NET je v nejjednodušší možné podobě fyzicky reprezentováno řízeným modulem s MSIL kódem, který je uložen v přenositelném a spustitelném PE (Portable Executable) souboru. PE soubor má standardní třípísmennou koncovku .exe, tudíž operační systém dovede sestavení aplikace .NET detekovat jako jakýkoliv jiný přímo spustitelný soubor.

Každé sestavení aplikace .NET obsahuje kromě řízeného modulu s MSIL kódem rovněž manifest. Manifest obsahuje metadata, která popisují aplikaci .NET. V manifestu jsou uvedeny tyto informace o sestavení aplikace .NET:
název sestavení aplikace .NET,
seznam souborů, z nichž je sestavení aplikace .NET složeno,
seznam exportovaných a importovaných datových typů,
číslo verze sestavení ve tvaru: Hlavní.Vedlejší.Překladové.Revizní,
textovou identifikaci kultury sestavení.
V sestavení aplikace .NET jsou ještě další součásti. Jde hlavně o typová metadata, jež podávají informace o všech datových typech, s nimiž aplikace pracuje. Poněvadž si sestavení nese s sebou typová metadata, je plně samopopisné. Ona samopopisnost sestavení je ohromným krokem vpřed, poněvadž aplikace .NET již není závislá na typových či objektových knihovnách, s nimiž vývojáři pracovali v dobách, kdy tvořili své programy podle modelu COM (Component Object Model). Sestavení aplikace .NET smí obsahovat také aplikační zdroje, což mohou být třeba obrázky, ikony, tabulky textových řetězců, soubory elektronické nápovědy a další potřebné elementy. V každém případě je v sestavení přítomen rovněž fragment strojového (nativního) kódu, jehož úkolem je po spuštění aplikace .NET načíst a inicializovat společné běhové prostředí CLR. O řízené exekuci aplikací .NET si budeme více povídat v následující podkapitole.
Řízená exekuce aplikace .NET
Předpokládejme, že jsme v jazyce C# 3.0 napsali jednoduchou aplikaci (třeba tu, jejíž zhotovení bylo obsahem předcházející lekce tohoto kurzu). Takováto aplikace je řízená, a proto ke svému běhu potřebuje vývojově-exekuční platformu Microsoft .NET Framework 3.5. Nyní se obeznámíme s fázemi, které tvoří proces řízené exekuce (zpracování nebo také běhu) libovolné aplikace .NET.
Když uživatel spustí aplikaci .NET poklepáním na její ikonu v Průzkumníkovi systému Windows, odehrají se tyto činnosti:
Operační systém (OS) vytvoří pro spouštěnou aplikaci nový fyzický proces. Pokud jste již absolvovali aktuální lekci kurzu jazyka C++, pak víte, že fyzický proces je jednotkou izolace, díky které může OS oddělit jednu spuštěnou aplikaci od jiné. Fyzický proces je mapován na paměťový prostor o jisté alokační kapacitě a je plně k dispozici spouštěné aplikaci a jejím potřebám.

Když zavaděč operačního systému přečte informace z hlavičky PE souboru aplikace .NET, zjistí, že se jedná o řízenou aplikaci. Všechny řízené aplikace potřebují ke svému běhu virtuální exekuční systém, poněvadž pouze ten je zodpovědný za management jejich životních cyklů. Proto zavaděč OS zabezpečí načtení a inicializaci společného běhového prostředí CLR.

Prostředí CLR vytvoří ve fyzickém procesu primární aplikační doménu a do ní umístí primární programové vlákno. Aplikační doménu si můžeme představit jako logický proces, jenž existuje v područí fyzického procesu, který vytvořil OS. Prostředí CLR se totiž nespoléhá pouze na izolační primitiva OS, ale vytváří si také svá vlastní, jimž říká aplikační domény. Každá aplikace .NET obsahuje alespoň jednu aplikační doménu, které se říká primární. Primární aplikační doména vystupuje jako logický proces, v němž bude aplikace .NET ve skutečnosti běžet. V jednom fyzickém procesu může koexistovat více aplikačních domén, přičemž v každé aplikační doméně může běžet jiná řízená aplikace. Výhodou aplikačních domén vůči fyzickým procesům jsou především nižší náklady, které se vážou k jejich správě. Příkazy aplikace .NET jsou zpracovávány na programovém vláknu. Každá řízená aplikace implicitně disponuje jedním programovým vláknem, které se nazývá primární. Primární programové vlákno (někdy se vláknu říká též podproces) je exekučním kanálem, na němž se bude odehrávat zpracování programových příkazů aplikace .NET.

Příkazy aplikace .NET jsou uloženy v podobě instrukcí mezijazyka MSIL v řízeném modulu příslušného sestavení. Je tedy nutné tyto příkazy načíst a podrobit exekuci. Zde se však trošku dostáváme do potíží, poněvadž jak jsme již uvedli, MSIL je pseudostrojový nízkoúrovňový jazyk. To má významné implikace: žádný z aktuálně dostupných procesorů nedovede instrukce jazyka MSIL vykonat přímo. Marně tedy máme v našem počítači osazen nejnovější vícejádrový procesor s podporou paralelní exekuce mikroinstrukcí, když ten neví, co to MSIL kód vůbec je. Proto potřebujeme softwarový stroj, který nám na požádání přeloží fragmenty MSIL kódu na příslušné instrukce strojového kódu. Tímto strojem je na platformě .NET Framework 3.5 Just-In-Time (JIT) překladač. JIT překladač načte vstupní bod aplikace .NET (což je hlavní funkce Main) a začne překládat zdejší příkazy z MSIL do x86 strojových instrukcí. Když jsou příkazy přeloženy, mohou být poskytnuty procesoru ke přímé exekuci. JIT překladač toho však dělá mnohem více než jen překlad MSIL kódu na požádání. Ještě před samotnou kompilací verifikační algoritmus testuje, zda načtený MSIL kód splňuje kritéria validity a typové bezpečnosti. Pokud by snad kód mohl být potenciálně nebezpečný, JIT překladač raději odmítne jeho kompilaci, než by vystavil uživatele bezpečnostnímu riziku.
Dále je JIT překladač schopen překládaný MSIL kód vhodně optimalizovat, a to podle procesoru, který je v dané počítačové stanici nainstalován. Optimalizace se dotýká kupříkladu procesorů třídy Intel Pentium 4 a novějších, jež operují s širokou instrukční sadou. Je tedy možné, že díky optimalizaci JIT překladače bude aplikace .NET běžet rychleji, než se původně očekávalo. Dalším plusem JIT překladače je algoritmus determinující jeho pracovní činnost: překladač totiž kompiluje pouze ty fragmenty MSIL kódu, které je doopravdy nutno přeložit. Pokud si aplikaci představíme jako množinu funkcí provádějících různé činnosti, pak JIT překladač převádí do strojového kódu pouze vybrané funkce, tedy diskrétní prvky množiny všech funkcí aplikace .NET. Když se nad tím zamyslíte, zjistíte, že takový pracovní model je mnohem lepší než překládat veškerý kód aplikace .NET (i takový, který nemusí být vůbec použit).
Konečně, jednou přeložené fragmenty MSIL kódu jsou ukládány v operační paměti pro příští použití. Pokud tedy v budoucnosti (samozřejmě v rámci jedné exekuční relace aplikace .NET) přijde požadavek na aktivaci nějaké funkce, jejíž MSIL kód již byl přeložen, JIT překladač nebude tento kód překládat znovu, ale raději použije již zkompilovaný x86 strojový kód. To je, jak jistě sami uznáte, zcela optimální řešení. Práce JIT překladače pokračuje, dokud není životní cyklus aplikace .NET u konce.

Když uživatel vydá pokyn k uzavření aplikace, ukončí se JIT překladač, zlikviduje se primární programové vlákno i primární aplikační doména, deaktivuje se společné běhové prostředí CLR a uvolní se všechny alokované paměťové prostředky. V závěru pak operační systém podrobí destrukci také fyzický proces aplikace .NET.