Přehled projektu Katana

Howard Dierking

ASP.NET Framework je již více než deset let a platforma umožnila vývoj nesčetných webů a služeb. S tím, jak se vyvíjí strategie vývoje webových aplikací, se architektura mohla vyvíjet postupně s technologiemi, jako jsou ASP.NET MVC a ASP.NET Webové rozhraní API. Vzhledem k tomu, že vývoj webových aplikací je dalším vývojovým krokem do světa cloud computingu, poskytuje projekt Katana základní sadu komponent pro ASP.NET aplikace, které umožňují, aby byly flexibilní, přenosné, jednoduché a poskytovaly lepší výkon – jinými slovy, projekt Katana cloud optimalizuje vaše ASP.NET aplikace.

Proč Katana - Proč teď?

Bez ohledu na to, jestli se jedná o vývojářskou architekturu nebo produkt pro koncové uživatele, je důležité pochopit základní motivaci k vytvoření produktu – a součástí toho je i znalost toho, pro koho byl produkt vytvořen. ASP.NET byl původně vytvořen s ohledem na dva zákazníky.

První skupinou zákazníků byly klasické vývojáře ASP. V té době byla technologie ASP jednou z primárních technologií pro vytváření dynamických webů a aplikací řízených daty propletením značek a skriptů na straně serveru. Modul runtime ASP poskytl skript na straně serveru se sadou objektů, které abstrahovaly základní aspekty základního protokolu HTTP a webového serveru a poskytovaly přístup k dalším službám, jako je správa stavu relací a aplikací, mezipaměť atd. I když jsou klasické aplikace ASP výkonné, jejich správa se stala výzvou, protože se zvětšovala jejich velikost a složitost. To bylo z velké části způsobeno nedostatkem struktury ve skriptovacích prostředích ve spojení s duplikací kódu, která je výsledkem prokládání kódu a značek. Aby bylo možné využít silné stránky klasické technologie ASP při řešení některých problémů, ASP.NET využili uspořádání kódu poskytované objektově orientovanými jazyky rozhraní .NET Framework a zároveň zachovali serverový programovací model, na který si klasičtí vývojáři ASP zvykli.

Druhou cílovou skupinou zákazníků pro ASP.NET jsou vývojáři obchodních aplikací pro Windows. Na rozdíl od klasických vývojářů ASP, kteří byli zvyklí psát kód HTML a generovat více značek HTML, vývojáři WinForms (jako vývojáři VB6 před nimi) byli zvyklí na návrh prostředí, které zahrnovalo plátno a bohatou sadu ovládacích prvků uživatelského rozhraní. První verze ASP.NET – označovaná také jako "Web Forms", poskytovala podobné prostředí při návrhu spolu s modelem událostí na straně serveru pro komponenty uživatelského rozhraní a sadou funkcí infrastruktury (například ViewState), které vytvořily bezproblémové vývojářské prostředí mezi programováním na straně klienta a serveru. Web Forms efektivně skryla bezstavovou povahu webu pod modelem stavových událostí, který znají vývojáři WinForms.

Problémy vyvolané historickým modelem

Čistým výsledkem byl vyspělý modul runtime s bohatými funkcemi a programovací model pro vývojáře. S tímto bohatstvím funkcí však přišlo několik výzev. Za prvé, architektura byla monolitická, přičemž logicky různorodé jednotky funkcí byly úzce svázány ve stejném System.Web.dll sestavení (například základní objekty HTTP s architekturou webových formulářů). Za druhé, ASP.NET byla zahrnuta jako součást většího rozhraní .NET Framework, což znamená, že doba mezi vydáními byla v řádu let. To ztěžovalo ASP.NET držet krok se všemi změnami, ke kterým dochází v rychle se rozvíjejícím vývoji webu. Nakonec System.Web.dll sám byl několika různými způsoby svázán s konkrétní možností hostování webu: Internetová informační služba (IIS).

Vývojové kroky: ASP.NET MVC a ASP.NET Web API

A ve vývoji pro web došlo k mnoha změnám! Webové aplikace se stále častěji vyvíjely jako řada malých, zaměřených komponent, nikoli velkých architektur. Počet komponent i frekvence, s jakou byly vydávány, se stále rychleji zvětšovaly. Bylo jasné, že udržování tempa s webem bude vyžadovat menší, oddělené a více zaměřené architektury než větší a více funkcí bohaté na funkce, proto tým ASP.NET provedl několik vývojových kroků, aby umožnil ASP.NET jako rodinu připojitelných webových komponent místo jediné architektury.

Jednou z prvních změn byl nárůst oblíbenosti známého vzoru návrhu MVC (model-view-controller) díky vývojovým architekturám pro web, jako je Ruby on Rails. Tento styl vytváření webových aplikací dal vývojáři větší kontrolu nad přirážkou aplikace při zachování oddělení přirážky a obchodní logiky, která byla jedním z počátečních prodejních bodů pro ASP.NET. Aby bylo možné vyhovět poptávce po tomto stylu vývoje webových aplikací, využila společnost Microsoft příležitost lépe se do budoucna rozvíjet ASP.NET MVC mimo pásmo (a nezahrnovat ji do rozhraní .NET Framework). ASP.NET MVC byl vydán jako nezávislý soubor ke stažení. To technickému týmu poskytlo flexibilitu při doručování aktualizací mnohem častěji, než bylo dříve možné.

Dalším významným posunem ve vývoji webových aplikací byl přechod od dynamických webových stránek generovaných serverem na statické počáteční značky s dynamickými oddíly stránky vygenerovanými skriptem na straně klienta, který komunikuje s back-endovými webovými rozhraními API prostřednictvím požadavků AJAX. Tento posun architektury pomohl posouvat vzestup webových rozhraní API a vývoj rozhraní ASP.NET Webové rozhraní API. Stejně jako v případě ASP.NET MVC poskytlo vydání rozhraní ASP.NET Web API další příležitost k dalšímu rozvoji ASP.NET jako modulárního rozhraní. Technický tým využil této příležitosti a vytvořil ASP.NET webové rozhraní API tak, aby nemělo žádné závislosti na žádném z základních typů rozhraní, které se nacházejí v System.Web.dll. To umožnilo dvě věci: zaprvé to znamenalo, že ASP.NET webové rozhraní API se mohlo vyvíjet zcela samostatným způsobem (a mohlo by pokračovat v rychlé iteraci, protože se dodává přes NuGet). Za druhé, protože System.Web.dll neexistovaly žádné externí závislosti, a proto žádné závislosti se službou IIS, ASP.NET webové rozhraní API zahrnovalo možnost spuštění na vlastním hostiteli (například v konzolové aplikaci, službě Windows atd.).

Budoucnost: Hbitá architektura

Díky oddělení komponent architektury od sebe a jejich následnému uvolnění v NuGetu by architektury mohly iterovat nezávisleji a rychleji. Kromě toho se výkon a flexibilita funkce samoobslužného hostování webového rozhraní API ukázala jako velmi atraktivní pro vývojáře, kteří pro své služby chtěli malého a jednoduchého hostitele . Ve skutečnosti se ukázalo jako tak atraktivní, že tuto schopnost chtěly i jiné architektury, a to ukázalo novou výzvu v tom, že každá architektura běžela ve svém vlastním hostitelském procesu na své vlastní základní adrese a musela být nezávisle spravována (spuštěna, zastavena atd.). Moderní webová aplikace obecně podporuje statické obsluhování souborů, dynamické generování stránek, webové rozhraní API a v poslední době i nabízená oznámení v reálném čase. Očekávání, že by každá z těchto služeb měla být spuštěna a spravována nezávisle, jednoduše nebylo reálné.

Potřebovali jsme jednu abstrakci hostování, která by vývojáři umožnila vytvořit aplikaci z různých komponent a architektur a pak ji spustit na podpůrném hostiteli.

Open Web Interface for .NET (OWIN)

Někteří členové komunity .NET se nechali inspirovat výhodami, které rack v komunitě Ruby dosáhl, a proto se chytli vytvořit abstrakci mezi webovými servery a komponentami architektury. Dva cíle návrhu pro abstrakci OWIN byly, že byla jednoduchá a měla nejmenší možné závislosti na jiných typech rozhraní. Tyto dva cíle pomáhají zajistit:

• Nové komponenty by se daly snadněji vyvíjet a používat.
• Aplikace je možné snadněji přenést mezi hostiteli a potenciálně celými platformami nebo operačními systémy.

Výsledná abstrakce se skládá ze dvou základních prvků. První je slovník prostředí. Tato datová struktura zodpovídá za uložení veškerého stavu potřebného ke zpracování požadavku a odpovědi HTTP a také všech relevantních stavů serveru. Slovník prostředí je definován takto:

IDictionary<string, object>

Webový server kompatibilní s OWIN zodpovídá za naplnění slovníku prostředí daty, jako jsou datové proudy těla a kolekce hlaviček pro požadavek a odpověď HTTP. Komponenty aplikace nebo architektury pak zodpovídnou za naplnění nebo aktualizaci slovníku dalšími hodnotami a zápis do datového proudu těla odpovědi.

Kromě určení typu pro slovník prostředí specifikace OWIN definuje seznam párů hodnot klíčů základního slovníku. Například následující tabulka obsahuje požadované klíče slovníku pro požadavek HTTP:

Název klíče	Popis hodnoty
"owin.RequestBody"	Stream s textem požadavku, pokud existuje. Stream.Null se může použít jako zástupný symbol, pokud neexistuje text požadavku. Viz Text požadavku.
"owin.RequestHeaders"	Hlavička IDictionary<string, string[]> požadavku. Viz Hlavičky.
"owin.RequestMethod"	Obsahující string metodu požadavku HTTP (např. "GET", ). "POST"
"owin.RequestPath"	Obsahující string cestu požadavku. Cesta MUSÍ být relativní ke kořenovému adresáři delegáta aplikace; viz Cesty.
"owin.RequestPathBase"	Obsahující string část cesty požadavku odpovídající kořenovému adresáři delegáta aplikace; viz Cesty.
"owin.RequestProtocol"	A string obsahující název a verzi protokolu (např. "HTTP/1.0" nebo "HTTP/1.1").
"owin.RequestQueryString"	Obsahující string komponentu řetězce dotazu v identifikátoru URI požadavku HTTP bez počátečního znaku "?" (např. "foo=bar&baz=quux"). Hodnota může být prázdný řetězec.
"owin.RequestScheme"	A string obsahující schéma identifikátoru URI použité pro požadavek (např. "http", "https"); viz Schéma identifikátoru URI.

Druhým klíčovým prvkem OWIN je delegát aplikace. Toto je podpis funkce, který slouží jako primární rozhraní mezi všemi komponentami v aplikaci OWIN. Definice delegáta aplikace je následující:

Func<IDictionary<string, object>, Task>;

Delegát aplikace je pak jednoduše implementací typu delegáta Func, kde funkce přijme slovník prostředí jako vstup a vrátí úlohu. Tento návrh má pro vývojáře několik důsledků:

• K zápisu komponent OWIN se vyžaduje velmi malý počet závislostí typů. To výrazně zvyšuje přístupnost OWIN vývojářům.
• Asynchronní návrh umožňuje abstrakci efektivně zpracovávat výpočetní prostředky, zejména při operacích náročných na vstupně-výstupní operace.
• Vzhledem k tomu, že delegát aplikace je atomická jednotka provádění a slovník prostředí se přenáší jako parametr delegáta, komponenty OWIN mohou být snadno zřetězený dohromady a vytvářet komplexní kanály zpracování HTTP.

Z hlediska implementace je OWIN specifikace (http://owin.org/html/owin.html). Jeho cílem není být další webová architektura, ale spíše specifikace toho, jak webové architektury a webové servery vzájemně spolupracují.

Pokud jste prozkoumali OWIN nebo Katana, možná jste si také všimli balíčku Owin NuGet a Owin.dll. Tato knihovna obsahuje jedno rozhraní [ IAppBuilder]/dotnet/api/microsoft.aspnetcore.builder.iapplicationbuilder), které formalizuje a kodifikuje spouštěcí sekvenci popsanou v části 4 specifikace OWIN. I když se k sestavení serverů OWIN nevyžaduje, rozhraní [IAppBuilder]/dotnet/api/microsoft.aspnetcore.builder.iapplicationbuilder) poskytuje konkrétní referenční bod a používá se komponentami projektu Katana.

Projekt Katana

Zatímco specifikace I Owin.dllOWIN jsou vlastněné komunitou a komunitou se provozují open source úsilí, projekt Katana představuje sadu komponent OWIN, které sice stále open source, ale vytváří a vydává je Microsoft. Tyto komponenty zahrnují komponenty infrastruktury, jako jsou hostitelé a servery, i funkční komponenty, jako jsou komponenty pro ověřování a vazby na architektury, jako jsou SignalR a ASP.NET Web API. Projekt má následující tři základní cíle:

• Přenosné – komponenty by měly být možné snadno nahradit novými komponentami, jakmile budou k dispozici. To zahrnuje všechny typy komponent, od architektury až po server a hostitele. Důsledkem tohoto cíle je, že architektury třetích stran můžou bez problémů běžet na serverech Microsoftu, zatímco architektury Microsoftu můžou potenciálně běžet na serverech a hostitelích třetích stran.
• Modulární/flexibilní – na rozdíl od mnoha architektur, které obsahují nesčetné množství funkcí, které jsou ve výchozím nastavení zapnuté, by komponenty projektu Katana měly být malé a zaměřené a měly by dát vývojáři aplikace kontrolu nad určením komponent, které se mají v aplikaci použít.
• Zjednodušená/ výkonná/škálovatelná – díky rozdělení tradičního pojmu architektury do sady malých zaměřených komponent, které explicitně přidal vývojář aplikace, může výsledná aplikace Katana spotřebovávat méně výpočetních prostředků a v důsledku toho zvládnout větší zatížení než u jiných typů serverů a architektur. Vzhledem k tomu, že požadavky aplikace vyžadují další funkce ze základní infrastruktury, je možné je přidat do kanálu OWIN, ale mělo by to být explicitní rozhodnutí ze strany vývojáře aplikace. Kromě toho nahraditelnost komponent nižší úrovně znamená, že jakmile budou k dispozici, mohou být bez problémů zavedeny nové vysoce výkonné servery, aby se zlepšil výkon aplikací OWIN, aniž by se tyto aplikace přerušily.

Začínáme s komponentami Katana

Když byla poprvé představena, jedním z aspektů architekturyNode.js , která okamžitě upoutala pozornost uživatelů, byla jednoduchost, s jakou bylo možné vytvořit a spustit webový server. Pokud byly cíle Katany rámovány s ohledem naNode.js, bylo by možné je shrnout tím, že Katana přináší mnoho výhod Node.js (a podobných architektur), aniž by vývojáři museli vyhodit všechno, co o vývoji ASP.NET webových aplikací ví. Aby toto tvrzení platilo, musí být zahájení práce s projektem Katana stejně jednoduché jako Node.js.

Vytváří se "Hello World!"

Jedním z hlavních rozdílů mezi vývojem v JavaScriptu a .NET je přítomnost (nebo absence) kompilátoru. Výchozím bodem jednoduchého serveru Katana je tedy projekt sady Visual Studio. Můžeme ale začít s nejmíněnějšími typy projektů: prázdným ASP.NET webovou aplikací.

Dále do projektu nainstalujeme balíček NuGet Microsoft.Owin.Host.SystemWeb . Tento balíček poskytuje server OWIN, který běží v kanálu požadavků ASP.NET. Najdete ho v galerii NuGet a můžete ho nainstalovat pomocí dialogového okna správce balíčků sady Visual Studio nebo konzoly správce balíčků pomocí následujícího příkazu:

install-package Microsoft.Owin.Host.SystemWeb

Instalací Microsoft.Owin.Host.SystemWeb balíčku se nainstaluje několik dalších balíčků jako závislostí. Jednou z těchto závislostí je Microsoft.Owinknihovna , která poskytuje několik pomocných typů a metod pro vývoj aplikací OWIN. Tyto typy můžeme použít k rychlému napsání následujícího serveru "hello world".

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Run(context =>
      {
         context.Response.ContentType = "text/plain";
         return context.Response.WriteAsync("Hello World!");
      });
   }
}

Tento velmi jednoduchý webový server je nyní možné spustit pomocí příkazu F5 sady Visual Studio a zahrnuje plnou podporu ladění.

Přepínání hostitelů

Ve výchozím nastavení se předchozí příklad "hello world" spouští v kanálu ASP.NET požadavků, který používá System.Web v kontextu služby IIS. To může samo o sobě přinést obrovskou hodnotu, protože nám to umožňuje těžit z flexibility a kompozibilnosti kanálu OWIN s možnostmi správy a celkovou vyspělostí služby IIS. Mohou však narazit na případy, kdy výhody poskytované službou IIS nejsou vyžadovány a přáním je menší a jednodušší hostitel. Co je tedy potřeba ke spuštění našeho jednoduchého webového serveru mimo službu IIS a System.Web?

Chcete-li ilustrovat cíl přenositelnosti, přechod z hostitele webového serveru na hostitele příkazového řádku vyžaduje jednoduše přidání nového serveru a závislosti hostitele do výstupní složky projektu a následné spuštění hostitele. V tomto příkladu budeme webový server hostovat v hostiteli Katana s názvem OwinHost.exe a použijeme server založený na Katana HttpListener. Podobně jako ostatní komponenty Katana se tyto komponenty získají z NuGetu pomocí následujícího příkazu:

install-package OwinHost

Z příkazového řádku pak můžeme přejít do kořenové složky projektu a jednoduše spustit OwinHost.exe příkaz (který byl nainstalován do složky tools příslušného balíčku NuGet). Ve výchozím nastavení je nakonfigurovaná tak, OwinHost.exe aby hledala server založený na HttpListener, takže není potřeba žádná další konfigurace. Při navigaci ve webovém prohlížeči se http://localhost:5000/ zobrazí aplikace, která teď běží v konzole nástroje .

Architektura Katana

Architektura komponent Katana rozděluje aplikaci do čtyř logických vrstev, jak je znázorněno níže: hostitel, server, middleware a aplikace. Architektura komponent je zahrnuta tak, aby implementace těchto vrstev bylo možné snadno nahradit, v mnoha případech bez nutnosti rekompilace aplikace.

Hostitel

Hostitel zodpovídá za:

• Správa základního procesu

• Orchestrace pracovního postupu, který má za následek výběr serveru a vytvoření kanálu OWIN, jehož prostřednictvím se budou zpracovávat požadavky.

  V současné době existují 3 primární možnosti hostování aplikací založených na Kataně:

IIS/ASP.NET: Pomocí standardních typů HttpModule a HttpHandler můžou kanály OWIN běžet ve službě IIS jako součást toku požadavků ASP.NET. ASP.NET podporu hostování povolíte instalací balíčku NuGet Microsoft.AspNet.Host.SystemWeb do projektu webové aplikace. Vzhledem k tomu, že služba IIS funguje jako hostitel i server, rozdíl mezi serverem a hostitelem OWIN je v tomto balíčku NuGet sjednocený, což znamená, že pokud používáte hostitele SystemWeb, vývojář nemůže nahradit implementaci alternativního serveru.

Vlastní hostitel: Sada komponent Katana dává vývojáři možnost hostovat aplikace ve vlastním procesu, ať už se jedná o konzolovou aplikaci, službu Windows atd. Tato funkce vypadá podobně jako možnost místního hostování, kterou poskytuje webové rozhraní API. Následující příklad ukazuje vlastní hostitele kódu webového rozhraní API:

static void Main()
{
    var baseAddress = new Uri("http://localhost:5000");

    var config = new HttpSelfHostConfiguration(baseAddress);
    config.Routes.MapHttpRoute("default", "{controller}");
       
    using (var svr = new HttpSelfHostServer(config))
    {
        svr.OpenAsync().Wait();
        Console.WriteLine("Press Enter to quit.");
        Console.ReadLine();
    }
}

Nastavení místního hostitele pro aplikaci Katana je podobné:

static void Main(string[] args)
{
    const string baseUrl = "http://localhost:5000/";

    using (WebApplication.Start<Startup>(new StartOptions { Url = baseUrl })) 
    {
        Console.WriteLine("Press Enter to quit.");
        Console.ReadKey();
    }
}

Jedním z hlavních rozdílů mezi příklady místního hostování webového rozhraní API a Katana je, že v příkladu místního hostitele Katana chybí konfigurační kód webového rozhraní API. Aby bylo možné povolit přenositelnost i kompozibilitnost, Katana odděluje kód, který spouští server, od kódu, který konfiguruje kanál zpracování požadavků. Kód, který konfiguruje webové rozhraní API, se pak nachází ve třídě Startup, která je navíc zadána jako parametr typu v souboru WebApplication.Start.

public class Startup
{
    public void Configuration(IAppBuilder app)
    {
        var config = new HttpConfiguration();
        config.Routes.MapHttpRoute("default", "{controller}");
        app.UseWebApi(config);
    }
}

Spouštěcí třída bude podrobněji popsána dále v článku. Kód potřebný ke spuštění procesu samoobslužného hostování Katana se ale nápadně podobá kódu, který dnes používáte v aplikacích ASP.NET Web API pro vlastní hostování.

OwinHost.exe: I když někteří budou chtít napsat vlastní proces pro spouštění webových aplikací Katana, mnozí by raději jednoduše spustili předem připravený spustitelný soubor, který může spustit server a spustit jejich aplikaci. V tomto scénáři sada komponent Katana obsahuje OwinHost.exe. Při spuštění z kořenového adresáře projektu spustí tento spustitelný soubor server (ve výchozím nastavení používá server HttpListener) a pomocí konvencí vyhledá a spustí třídu spuštění uživatele. Pro podrobnější kontrolu poskytuje spustitelný soubor řadu dalších parametrů příkazového řádku.

Server

Zatímco hostitel je zodpovědný za spuštění a údržbu procesu, ve kterém běží aplikace, odpovědností serveru je otevřít síťový soket, naslouchat žádostem a odesílat je prostřednictvím kanálu komponent OWIN určeného uživatelem (jak jste si už možná všimli, tento kanál je zadaný ve třídě Startup vývojáře aplikace). V současné době projekt Katana zahrnuje dvě implementace serveru:

• Microsoft.Owin.Host.SystemWeb: Jak už jsme zmínili, služba IIS v souladu s kanálem ASP.NET funguje jako hostitel i server. Proto při výběru této možnosti hostování služba IIS spravuje otázky na úrovni hostitele, jako je aktivace procesů a naslouchá požadavkům HTTP. U ASP.NET webových aplikací pak odešle požadavky do kanálu ASP.NET. Hostitel Katana SystemWeb registruje ASP.NET HttpModule a HttpHandler k zachytávání požadavků při jejich průchodu kanálem HTTP a jejich odesílání přes uživatelem zadaný kanál OWIN.
• Microsoft.Owin.Host.HttpListener: Jak název naznačí, tento server Katana používá třídu HttpListener rozhraní .NET Framework k otevření soketu a odesílání požadavků do kanálu OWIN zadaného vývojářem. V současné době se jedná o výchozí výběr serveru pro rozhraní API místního hostitele Katana i pro OwinHost.exe.

Middleware nebo architektura

Jak už jsme zmínili, když server přijme požadavek od klienta, zodpovídá za jeho předání kanálem komponent OWIN, které jsou určené spouštěcím kódem vývojáře. Tyto komponenty kanálu se označují jako middleware.
Na základní úrovni musí komponenta middlewaru OWIN jednoduše implementovat delegáta aplikace OWIN, aby byla volatelná.

Func<IDictionary<string, object>, Task>

Aby se ale zjednodušil vývoj a složení komponent middlewaru, podporuje Katana několik konvencí a pomocných typů pro komponenty middlewaru. Nejběžnější z nich je OwinMiddleware třída . Vlastní komponenta middlewaru sestavená pomocí této třídy by vypadala podobně jako následující:

public class LoggerMiddleware : OwinMiddleware
{
    private readonly ILog _logger;
 
    public LoggerMiddleware(OwinMiddleware next, ILog logger) : base(next)
    {
        _logger = logger;
    }
 
    public override async Task Invoke(IOwinContext context)
    {
        _logger.LogInfo("Middleware begin");
        await this.Next.Invoke(context);
        _logger.LogInfo("Middleware end");
    }
}

Tato třída je odvozena z OwinMiddleware, implementuje konstruktor, který přijímá instanci dalšího middlewaru v kanálu jako jeden ze svých argumentů a poté ji předá do základního konstruktoru. Další argumenty používané ke konfiguraci middlewaru se také deklarují jako parametry konstruktoru za dalším parametrem middlewaru.

Za běhu se middleware spouští prostřednictvím přepsané Invoke metody. Tato metoda přijímá jeden argument typu OwinContext. Tento kontextový objekt poskytuje Microsoft.Owin balíček NuGet popsaný výše a poskytuje přístup silného typu k požadavku, odpovědi a slovníku prostředí spolu s několika dalšími typy pomocných rutin.

Třídu middlewaru je možné snadno přidat do kanálu OWIN ve spouštěcím kódu aplikace následujícím způsobem:

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Use<LoggerMiddleware>(new TraceLogger());

   }
}

Vzhledem k tomu, že infrastruktura Katana jednoduše vytváří kanál komponent middlewaru OWIN, a protože komponenty jednoduše potřebují podporovat delegáta aplikace, aby se mohli zapojit do kanálu, můžou se komponenty middlewaru pohybovat ve složitosti od jednoduchých protokolovacích nástrojů až po celé architektury, jako jsou ASP.NET, webové rozhraní API nebo SignalR. Například přidání ASP.NET webového rozhraní API do předchozího kanálu OWIN vyžaduje přidání následujícího spouštěcího kódu:

public class Startup
{
   public void Configuration(IAppBuilder app)
   {
      app.Use<LoggerMiddleware>(new TraceLogger());

      var config = new HttpConfiguration();
      // configure Web API 
      app.UseWebApi(config);

      // additional middleware registrations            
   }
}

Infrastruktura Katana sestaví kanál komponent middlewaru na základě pořadí, ve kterém byly přidány do objektu IAppBuilder v metodě Configuration. V našem příkladu pak LoggerMiddleware dokáže zpracovat všechny požadavky, které kanálem procházejí, bez ohledu na to, jak se tyto požadavky nakonec zpracovávají. To umožňuje efektivní scénáře, kdy komponenta middlewaru (např. komponenta ověřování) může zpracovávat požadavky na kanál, který obsahuje více komponent a architektur (např. ASP.NET Webové rozhraní API, SignalR a statický souborový server).

Aplikace

Jak je vidět na předchozích příkladech, projekt OWIN a Katana by se neměly považovat za nový aplikační programovací model, ale spíše jako abstrakci pro oddělení aplikačních programovacích modelů a architektur od serverové a hostitelské infrastruktury. Například při sestavování aplikací webového rozhraní API bude vývojářská architektura dál používat rozhraní ASP.NET Webové rozhraní API bez ohledu na to, jestli aplikace běží v kanálu OWIN pomocí komponent z projektu Katana. Jediným místem, kde bude kód související s OWIN viditelný pro vývojáře aplikace, bude spouštěcí kód aplikace, kde vývojář vytvoří kanál OWIN. Ve spouštěcím kódu vývojář zaregistruje řadu příkazů UseXx, obecně jeden pro každou komponentu middlewaru, která bude zpracovávat příchozí požadavky. Toto prostředí bude mít stejný účinek jako registrace modulů HTTP v aktuálním prostředí System.Web. Na konci kanálu se obvykle zaregistruje větší middleware architektury, například ASP.NET Web API nebo SignalR . Průřezové komponenty middlewaru, například pro ověřování nebo ukládání do mezipaměti, se obecně registrují na začátku kanálu, aby zpracovávaly požadavky na všechna rozhraní a komponenty zaregistrované později v kanálu. Toto oddělení komponent middlewaru od sebe navzájem a od základních komponent infrastruktury umožňuje, aby se komponenty vyvíjely různou rychlostí a zároveň se zajistilo, že celkový systém zůstane stabilní.

Komponenty – balíčky NuGet

Stejně jako mnoho současných knihoven a architektur se i komponenty projektu Katana doručují jako sada balíčků NuGet. Pro nadcházející verzi 2.0 vypadá graf závislostí balíčku Katana takto. (Větší zobrazení zobrazíte kliknutím na obrázek.)

Téměř každý balíček v projektu Katana přímo nebo nepřímo závisí na balíčku Owin. Možná si pamatujete, že se jedná o balíček, který obsahuje rozhraní IAppBuilder, které poskytuje konkrétní implementaci spouštěcí sekvence aplikace popsané v části 4 specifikace OWIN. Mnoho balíčků navíc závisí na microsoft.Owin, který poskytuje sadu pomocných typů pro práci s požadavky a odpověďmi HTTP. Zbývající část balíčku je možné klasifikovat jako hostující balíčky infrastruktury (servery nebo hostitelé) nebo jako middleware. Balíčky a závislosti, které jsou pro projekt Katana externí, se zobrazí oranžově.

Hostitelská infrastruktura pro Katana 2.0 zahrnuje servery založené na SystemWeb a HttpListener, balíček OwinHost pro spouštění aplikací OWIN pomocí OwinHost.exe a balíček Microsoft.Owin.Hosting pro aplikace OWIN na vlastním hostiteli (např. konzolová aplikace, služba Windows atd.).

Pro Katana 2.0 se komponenty middlewaru primárně zaměřují na poskytování různých prostředků ověřování. K dispozici je jedna další komponenta middlewaru pro diagnostiku, která umožňuje podporu úvodní stránky a chybové stránky. S tím, jak OWIN roste do abstrakce hostování, bude se zvyšovat i ekosystém komponent middlewaru, které vyvíjí Microsoft i třetí strany.

Závěr

Cílem projektu Katana od jeho počátku nebylo vytvořit a tím donutit vývojáře, aby se naučili ještě další webovou architekturu. Cílem bylo spíše vytvořit abstrakci, která vývojářům webových aplikací .NET poskytne větší výběr, než bylo dříve možné. Díky rozdělení logických vrstev typického zásobníku webových aplikací na sadu nahraditelných komponent umožňuje projekt Katana, aby se komponenty v celém zásobníku vylepšily s libovolnou rychlostí, která pro tyto komponenty dává smysl. Díky vytváření všech komponent na základě jednoduché abstrakce OWIN umožňuje Katana přenášet architektury a aplikace, které jsou na nich postaveny, na různých serverech a hostitelích. Tím, že dává vývojáři kontrolu nad zásobníkem, Katana zajistí, aby vývojář zvolil maximální volbu ohledně toho, jak jednoduchý nebo jak by měl být její webový zásobník bohatý na funkce.

Další informace o Kataně

• Projekt Katana na GitHubu: https://github.com/aspnet/AspNetKatana/.
• Video: The Katana Project - OWIN for ASP.NET, autor Howard Dierking.

Poděkování

• Rick Anderson: (Twitter @RickAndMSFT ) Rick je vedoucí programátor pro Microsoft se zaměřením na Azure a MVC.
• Scott Hanselman: (twitter @shanselman )
• Jon Galloway: (twitter @jongalloway )