プロジェクト Katana の概要An Overview of Project Katana

によってHoward dierking がby Howard Dierking

10 年以上にわたってきましたが、ASP.NET フレームワークとプラットフォームが無数の Web サイトとサービスの開発を有効にします。The ASP.NET Framework has been around for over ten years, and the platform has enabled the development of countless Web sites and services. Web アプリケーションの開発戦略に進化してきましたが、フレームワークに ASP.NET MVC や ASP.NET Web API などのテクノロジの手順で展開できるされています。As Web application development strategies have evolved, the framework has been able to evolve in step with technologies like ASP.NET MVC and ASP.NET Web API. プロジェクトのように Web アプリケーションの開発では、クラウド コンピューティングの世界に次の革新的な手順を受け取り、 Katanaに柔軟で移植可能で、有効にすると、ASP.NET アプリケーション コンポーネントの基になるセットを提供します。軽量で、パフォーマンスの向上 – と別の方法で、プロジェクトKatanaクラウドは、ASP.NET アプリケーションを最適化します。As Web application development takes its next evolutionary step into the world of cloud computing, project Katana provides the underlying set of components to ASP.NET applications, enabling them to be flexible, portable, lightweight, and provide better performance – put another way, project Katana cloud optimizes your ASP.NET applications.

なぜ Katana – なぜ今取り組むでしょうか。Why Katana – Why Now?

いずれかが開発者のフレームワークやエンドユーザーによる製品を説明するかどうかにかかわらずが基になる動機を作成するために重要です – 製品とその一部は、製品をに対して作成されたユーザーを知ることが含まれています。Regardless whether one is discussing a developer framework or end-user product, it's important to understand the underlying motivations for creating the product – and part of that includes knowing who the product was created for. ASP.NET は、2 人の顧客を念頭に最初に作成されました。ASP.NET was originally created with two customers in mind.

顧客の最初のグループは、クラシック ASP 開発者でした。The first group of customers was classic ASP developers. 時点では、ASP はマークアップとサーバー側スクリプトに組み込む、動的なデータ ドリブン Web サイトおよびアプリケーションを作成するための主要なテクノロジのいずれかでした。At the time, ASP was one of the primary technologies for creating dynamic, data-driven Web sites and applications by interweaving markup and server-side script. ASP のランタイムは、基になる HTTP プロトコルと Web サーバーの主要な要素を抽象化され、キャッシュなどの追加へのアクセスは、このようなセッションとアプリケーションの状態管理をサービス提供するオブジェクトの一連のサーバー側スクリプトを指定します。強力ですが、従来の ASP アプリケーションはサイズと複雑さで遊んだりするように管理するの困難になりました。The ASP runtime supplied server-side script with a set of objects that abstracted core aspects of the underlying HTTP protocol and Web server and provided access to additional services such session and application state management, cache, etc. While powerful, classic ASP applications became a challenge to manage as they grew in size and complexity. これは、主にスクリプト環境のコードとマークアップのインターリーブによるコードの重複と組み合わせると、構造がないことによるものでした。This was largely due to the lack of structure found in scripting environments coupled with the duplication of code resulting from the interleaving of code and markup. その課題の一部に対処するときに、従来の ASP の長所を活用大文字にする、するために ASP.NET を活かして、サーバー側のプログラミング モデルを維持しながら、.NET Framework のオブジェクト指向言語によって提供されるコードの編成どの classic ASP を開発者が使い慣れたまで増加しました。In order to capitalize on the strengths of classic ASP while addressing some of its challenges, ASP.NET took advantage of the code organization provided by the object-oriented languages of the .NET Framework while also preserving the server-side programming model to which classic ASP developers had grown accustomed.

ASP.NET の対象顧客の 2 番目のグループには、Windows ビジネス アプリケーション開発者がでした。The second group of target customers for ASP.NET was Windows business application developers. 従来の ASP 開発者が HTML マークアップと複数の HTML マークアップを生成するコードを記述することに慣れていたのとは異なり (前に VB6 開発者) のような WinForms 開発者のキャンバスとユーザーの豊富なセットが含まれているデザイン時の操作に慣れていたインターフェイスを制御します。Unlike classic ASP developers, who were accustomed to writing HTML markup and the code to generate more HTML markup, WinForms developers (like the VB6 developers before them) were accustomed to a design time experience that included a canvas and a rich set of user interface controls. ASP.NET – の最初のバージョンとも呼ばれます"Web Forms"提供されるユーザー インターフェイス コンポーネントのサーバー側のイベント モデルとインフラストラクチャの機能 (ViewState) などの一連のようなデザイン時のエクスペリエンス、シームレスな開発エクスペリエンスを作成するにはクライアントとサーバー側プログラミングの間The first version of ASP.NET – also known as "Web Forms" provided a similar design time experience along with a server-side event model for user interface components and a set of infrastructure features (such as ViewState) to create a seamless developer experience between client and server side programming. Web フォームは、WinForms 開発者がステートフルのイベント モデルでは、Web のステートレスな性質を効果的に hid します。Web Forms effectively hid the Web's stateless nature under a stateful event model that was familiar to WinForms developers.

過去のモデルによって発生した問題Challenges Raised by the Historical Model

最終的な結果は、成熟した、機能豊富なランタイムと開発者のプログラミング モデルでした。The net result was a mature, feature-rich runtime and developer programming model. ただし、その機能豊富な注目すべきいくつかの課題が付属しています。However, with that feature-richness came a couple notable challenges. 最初に、フレームワークがモノリシックの論理的に個別の単位数を同じ System.Web.dll アセンブリ (たとえば、Web フォーム フレームワークを使用 core HTTP オブジェクト) に緊密に連携する機能。Firstly, the framework was monolithic, with logically disparate units of functionality being tightly coupled in the same System.Web.dll assembly (for example, the core HTTP objects with the Web forms framework). 次に、ASP.NET を大規模な .NET Framework の一部として含まれている、年間の順序があったリリース間の時間。Secondly, ASP.NET was included as a part of the larger .NET Framework, which meant that the time between releases was on the order of years. これで、ASP.NET のすべての Web 開発を急速に進化で発生した変更のペースに困難になります。This made it difficult for ASP.NET to keep pace with all of the changes happening in rapidly evolving Web development. 最後に、System.Web.dll 自体は、特定の Web ホスティングの選択肢をいくつかの異なる方法で結合されました。インターネット インフォメーション サービス (IIS)。Finally, System.Web.dll itself was coupled in a few different ways to a specific Web hosting option: Internet Information Services (IIS).

革新的な手順:ASP.NET MVC と ASP.NET Web APIEvolutionary steps: ASP.NET MVC and ASP.NET Web API

Web 開発で多数の変更が発生しています。And lots of change was happening in Web development! Web アプリケーションは、一連の小さい、大規模なフレームワークではなく、コンポーネントの焦点にますます開発されているされました。Web applications were increasingly being developed as a series of small, focused components rather than large frameworks. これまで高速のレートで上昇を見せていた、リリースされた頻度だけでなく、コンポーネントの数。The number of components as well as the frequency with which they were released was increasing at an ever faster rate. Web に追従が大きいと複数の機能豊富ではなくしたがって小さく、分離されたより対象を絞ったを取得するフレームワークをしなければ明確だ、 ASP.NET チームは時間のファミリとして ASP.NET を有効にするいくつかの革新的な手順1 つのフレームワークではなく、プラグ可能な Web コンポーネントします。It was clear that keeping pace with the Web would require frameworks to get smaller, decoupled and more focused rather than larger and more feature-rich, therefore the ASP.NET team took several evolutionary steps to enable ASP.NET as a family of pluggable Web components rather than a single framework.

初期の変更の 1 つが、Rails の Ruby などの Web 開発フレームワークに協力してくれた、よく知られているモデル-ビュー-コント ローラー (MVC) デザイン パターンの人気上昇します。One of the early changes was the rise in popularity of the well-known model-view-controller (MVC) design pattern thanks to Web development frameworks like Ruby on Rails. このスタイルの Web アプリケーションを構築する開発者に提供されましたが ASP.NET の初期のセールス ポイントのいずれかのマークアップとビジネス ロジックの分離を維持したまま、アプリケーションのマークアップを制御します。This style of building Web applications gave the developer greater control over her application's markup while still preserving the separation of markup and business logic, which was one of the initial selling points for ASP.NET. このスタイルの Web アプリケーションの開発の需要を満たすためには、Microsoft が自身を配置することで将来ことをお勧め帯域外の ASP.NET MVC の開発(および、.NET Framework に含まれません)。To meet the demand for this style of Web application development, Microsoft took the opportunity to position itself better for the future by developing ASP.NET MVC out of band (and not including it in the .NET Framework). ASP.NET MVC は、個別のダウンロードとしてリリースされました。ASP.NET MVC was released as an independent download. これにより、エンジニア リング チームは柔軟になっていた、以前よりもより頻繁に更新プログラムを配信します。This gave the engineering team the flexibility to deliver updates much more frequently than had been previously possible.

Web アプリケーションの開発のもう 1 つの大きな変化が、サーバーによって生成される動的な Web ページからクライアント側スクリプトとの通信から生成されたページのセクションでは動的で静的な初期マークアップへの移行バックエンド Web Api の使用AJAX 要求します。Another major shift in Web application development was the shift from dynamic, server-generated Web pages to static initial markup with dynamic sections of the page generated from client-side script communicating with backend Web APIs through AJAX requests. このアーキテクチャのシフトでは、Web Api の上昇と ASP.NET Web API フレームワークの開発を促進を支援します。This architectural shift helped propel the rise of Web APIs, and the development of the ASP.NET Web API framework. ASP.NET MVC、する場合などは、ASP.NET Web API のリリースには、ASP.NET のモジュール性の高いフレームワークとしてさらに進化する別の機会が用意されています。As in the case of ASP.NET MVC, the release of ASP.NET Web API provided another opportunity to evolve ASP.NET further as a more modular framework. 営業案件のエンジニア リング チームが利用およびSystem.Web.dll で検出されたコア フレームワークの型のいずれかの依存関係があるないように、ASP.NET Web API をビルドします。The engineering team took advantage of the opportunity and built ASP.NET Web API such that it had no dependencies on any of the core framework types found in System.Web.dll. これは、2 つの処理を有効になって: 最初に、そのため、自己完結型の方法で ASP.NET Web API の進化でした (および NuGet 経由で配信されるため、すばやく反復処理し続ける可能性があります)。This enabled two things: first, it meant that ASP.NET Web API could evolve in a completely self-contained manner (and it could continue to iterate quickly because it is delivered via NuGet). 第 2 に、System.Web.dll、外部の依存関係と、そのため、IIS に依存関係のないがないため、ASP.NET Web API に含まれる (たとえばのコンソール アプリケーション、Windows サービスなど) のカスタム ホストで実行する機能Second, because there were no external dependencies to System.Web.dll, and therefore, no dependencies to IIS, ASP.NET Web API included the capability to run in a custom host (for example, a console application, Windows service, etc.)

今後:敏捷性向上のフレームワークThe Future: A Nimble Framework

フレームワークを今すぐでしたから 1 つ別のフレームワークのコンポーネントを分離し、それらを NuGet でリリース、より個別にかつより迅速に反復処理します。By decoupling framework components from one another and then releasing them on NuGet, frameworks could now iterate more independently and more quickly. 機能と Web API の自己ホスト機能の柔軟性のことを望む開発者にとって非常に魅力的なさらに、支障を小型で軽量のホストサービス。Additionally, the power and flexibility of Web API's self-hosting capability proved very attractive to developers who wanted a small, lightweight host for their services. わかりました。 そのために魅力的な、実際には、その他のフレームワークは、この機能も必要およびという課題が表面化これで、各フレームワークを独自のベース アドレスで、独自のホスト プロセスで実行された、(開始、停止など) を管理するために必要とは独立しています。It proved so attractive, in fact, that other frameworks also wanted this capability, and this surfaced a new challenge in that each framework ran in its own host process on its own base address and needed to be managed (started, stopped, etc.) independently. モダン Web アプリケーションは、一般に、静的ファイル サービス、動的なページの生成、Web API、およびより最近リアルタイム-時間やプッシュ通知をサポートします。A modern Web application generally supports static file serving, dynamic page generation, Web API, and more recently real-time/push notifications. これらの各サービスが実行し、は別に管理が必要ですが単に現実的です。Expecting that each of these services should be run and managed independently was simply not realistic.

必要なものはさまざまなコンポーネントと、フレームワークのさまざまなアプリケーションを作成する開発者を有効にし、サポートのホストでそのアプリケーションを実行する単一のホスティング抽象化が発生しました。What was needed was a single hosting abstraction that would enable a developer to compose an application from a variety of different components and frameworks, and then run that application on a supporting host.

オープンな Web Interface for .NET (OWIN)The Open Web Interface for .NET (OWIN)

によって実現されるメリット触発ラックで Ruby のコミュニティでは、.NET コミュニティのメンバーがいくつか設定 Web サーバーおよびフレームワーク コンポーネント間の抽象化を作成します。Inspired by the benefits achieved by Rack in the Ruby community, several members of the .NET community set out to create an abstraction between Web servers and framework components. OWIN 抽象化のための 2 つの設計目標は、単純だし、他のフレームワーク型に最小限の可能な依存関係をかかったでした。Two design goals for the OWIN abstraction were that it was simple and that it took the fewest possible dependencies on other framework types. これら 2 つの目標はヘルプを確認します。These two goals help ensure:

  • 新しいコンポーネントがより簡単に開発し、使用します。New components could be more easily developed and consumed.
  • ホストと可能性のある全体のプラットフォームまたはオペレーティング システムの間には、アプリケーションをより簡単に移植する可能性があります。Applications could be more easily ported between hosts and potentially entire platforms/operating systems.

結果の抽象化は、2 つの主要な要素で構成されます。The resulting abstraction consists of two core elements. 最初は、環境のディクショナリです。The first is the environment dictionary. このデータ構造は、すべての HTTP 要求と応答、さらに、関連するサーバーの状態を処理するために必要な状態を格納する責任を負います。This data structure is responsible for storing all of the state necessary for processing an HTTP request and response, as well as any relevant server state. 環境のディクショナリの定義は次のとおりです。The environment dictionary is defined as follows:

IDictionary<string, object>

OWIN と互換性のある Web サーバーは、本文ストリームと、HTTP 要求と応答のヘッダー コレクションなどのデータを使用して環境ディクショナリを設定します。An OWIN-compatible Web server is responsible for populating the environment dictionary with data such as the body streams and header collections for an HTTP request and response. 設定または追加の値のディクショナリを更新し、応答のボディ ストリームに書き込むアプリケーションまたはフレームワーク コンポーネントの責任です。It is then the responsibility of the application or framework components to populate or update the dictionary with additional values and write to the response body stream.

環境のディクショナリの種類を指定するだけでなく、OWIN 仕様は、core ディクショナリのキー値ペアのリストを定義します。In addition to specifying the type for the environment dictionary, the OWIN specification defines a list of core dictionary key value pairs. たとえば、次の表は、HTTP 要求の必要な dictionary のキーを示しています。For example, the following table shows the required dictionary keys for an HTTP request:

キー名Key Name 値の説明Value Description
"owin.RequestBody" 存在する場合は、要求本文を含む Stream。A Stream with the request body, if any. 要求本文がない場合、Stream.Null はプレース ホルダーとして使用できます。Stream.Null MAY be used as a placeholder if there is no request body. 参照してください要求本文します。See Request Body.
"owin.RequestHeaders" IDictionary<string, string[]>の要求ヘッダー。An IDictionary<string, string[]> of request headers. 参照してくださいヘッダーします。See Headers.
"owin.RequestMethod" Astring要求の HTTP 要求メソッドを格納している (例: "GET""POST")。A string containing the HTTP request method of the request (e.g., "GET", "POST").
"owin.RequestPath" Astring要求パスを格納しています。A string containing the request path. 「ルート」、アプリケーション デリゲートの相対パスでなければなりません参照してくださいパスします。The path MUST be relative to the "root" of the application delegate; see Paths.
"owin.RequestPathBase" Astringを参照してください。 アプリケーション デリゲートの"root"に対応する要求パスの部分を含むパスします。A string containing the portion of the request path corresponding to the "root" of the application delegate; see Paths.
"owin.RequestProtocol" Astringプロトコルの名前とバージョンを格納している (例:"HTTP/1.0"または"HTTP/1.1")。A string containing the protocol name and version (e.g. "HTTP/1.0" or "HTTP/1.1").
"owin.RequestQueryString" Astring先頭に追加しない HTTP 要求の URI のクエリ文字列のコンポーネントを含む"?"(例: "foo=bar&baz=quux")。A string containing the query string component of the HTTP request URI, without the leading "?" (e.g., "foo=bar&baz=quux"). 空の文字列値があります。The value may be an empty string.
"owin.RequestScheme" Astring要求に使用される URI スキームを格納している (例: "http""https"); を参照してくださいURI スキームします。A string containing the URI scheme used for the request (e.g., "http", "https"); see URI Scheme.

OWIN の 2 番目のキー要素は、アプリケーション デリゲートです。The second key element of OWIN is the application delegate. これは、OWIN アプリケーションのすべてのコンポーネント間のプライマリ インターフェイスとして機能する関数のシグネチャです。This is a function signature which serves as the primary interface between all components in an OWIN application. アプリケーション デリゲートの定義は次のとおりです。The definition for the application delegate is as follows:

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

アプリケーション デリゲートでは、Func デリゲート型、関数が入力として環境のディクショナリを受け入れるし、タスクを返しますの実装では単にできるようになります。The application delegate then is simply an implementation of the Func delegate type where the function accepts the environment dictionary as input and returns a Task. この設計には、開発者向けのいくつかの影響があります。This design has several implications for developers:

  • OWIN コンポーネントを作成するために必要な種類の依存関係の数が非常に少ないがあります。There are a very small number of type dependencies required in order to write OWIN components. これは、開発者に OWIN のアクセシビリティが大幅に向上します。This greatly increases the accessibility of OWIN to developers.
  • 非同期デザインでは、コンピューティング リソース、特に多くの I/O 処理を要する操作の処理の効率を抽象化を使用できます。The asynchronous design enables the abstraction to be efficient with its handling of computing resources, particularly in more I/O intensive operations.
  • アプリケーション デリゲートは、実行のアトミック単位と OWIN コンポーネントを簡単に連結できるため、環境のディクショナリは、デリゲートのパラメーターとして送信されるが、ため、複雑な HTTP を処理パイプラインを作成するためです。Because the application delegate is an atomic unit of execution and because the environment dictionary is carried as a parameter on the delegate, OWIN components can be easily chained together to create complex HTTP processing pipelines.

OWIN は、仕様、実装の観点からです (http://owin.org/html/owin.html)。From an implementation perspective, OWIN is a specification (http://owin.org/html/owin.html). その目標は、次の Web フレームワークが Web フレームワークと Web サーバーの対話方法に関する仕様ではなく、ありません。Its goal is not to be the next Web framework, but rather a specification for how Web frameworks and Web servers interact.

調査した場合OWINまたはKatana、する可能性がありますもお気付き、 Owin NuGet パッケージOwin.dll とします。If you've investigated OWIN or Katana, you may also have noticed the Owin NuGet package and Owin.dll. このライブラリには、1 つのインターフェイスが含まれています。 IAppBuilder、形式化しで説明されているスタートアップ シーケンスを体系をセクション 4 OWIN 仕様の。This library contains a single interface, IAppBuilder, which formalizes and codifies the startup sequence described in section 4 of the OWIN specification. OWIN のサーバーを構築するためには必要ありません、 IAppBuilderインターフェイスは、具象参照ポイントを提供し、Katana プロジェクト コンポーネントによって使用されます。While not required in order to build OWIN servers, the IAppBuilder interface provides a concrete reference point, and it is used by the Katana project components.

プロジェクト KatanaProject Katana

両方、 OWIN仕様とOwin.dll所有コミュニティやコミュニティのオープン ソースの作業を実行するには、 Katanaプロジェクトは、OWIN のセットを表しますコンポーネントもオープン ソースの中をビルドして、Microsoft によってリリースします。Whereas both the OWIN specification and Owin.dll are community owned and community run open source efforts, the Katana project represents the set of OWIN components that, while still open source, are built and released by Microsoft. これらのコンポーネントはホストやサーバーなどのインフラストラクチャ コンポーネントと認証コンポーネントやフレームワークへのバインドなどの機能コンポーネントの両方をなど、 SignalRASP.NET WebAPIします。These components include both infrastructure components, such as hosts and servers, as well as functional components, such as authentication components and bindings to frameworks such as SignalR and ASP.NET Web API. プロジェクトには、次の 3 つの高レベル目標があります。The project has the following three high level goals:

  • ポータブル– コンポーネントは、利用可能になる新しいコンポーネントを簡単に置換できる必要があります。Portable – Components should be able to be easily substituted for new components as they become available. これには、すべての種類サーバーとホストするためにフレームワークからのコンポーネントにはが含まれます。This includes all types of components, from the framework to the server and host. この目標は、Microsoft フレームワークがサード パーティのサーバーとホストで実行できる可能性があるときに、サード パーティ製フレームワークできますマイクロソフトのサーバーで実行シームレスにことです。The implication of this goal is that third party frameworks can seamlessly run on Microsoft servers while Microsoft frameworks can potentially run on third party servers and hosts.
  • モジュール/柔軟な– 小規模とフォーカスがある、にコンポーネントを判断することで、アプリケーション開発者にコントロールを与える無数の既定で有効にする機能を含むさまざまなフレームワークとは異なり Katana プロジェクト コンポーネントがあります自分のアプリケーションで使用します。Modular/flexible– Unlike many frameworks which include a myriad of features that are turned on by default, Katana project components should be small and focused, giving control over to the application developer in determining which components to use in her application.
  • ライトウェイト/パフォーマンスの高い/スケーラブルな– フレームワークの従来の概念の小さなセットに分割することにより追加される明示的にアプリケーションの開発者によって、結果として得られる Katana アプリケーションはより少ないコンピューティングを使用できるコンポーネントの重点を置いています。リソース、およびその結果、他のサーバーとフレームワークの型よりも、負荷の増加を処理します。Lightweight/performant/scalable – By breaking the traditional notion of a framework into a set of small, focused components which are added explicitly by the application developer, a resulting Katana application can consume fewer computing resources, and as a result, handle more load, than with other types of servers and frameworks. アプリケーションの要件を満たすには、基になるインフラストラクチャからより多くの機能が必要で、OWIN パイプラインに追加できるものが、アプリケーション開発者、明示的な意思決定する必要があります。As the requirements of the application demand more features from the underlying infrastructure, those can be added to the OWIN pipeline, but that should be an explicit decision on the part of the application developer. さらを可能になる、新しい高パフォーマンス サーバーにシームレスに導入できますそれらのアプリケーションを中断することがなく、OWIN アプリケーションのパフォーマンスを向上させるために下位レベルのコンポーネントの代替性を意味します。Additionally, the substitutability of lower level components means that as they become available, new high performance servers can seamlessly be introduced to improve the performance of OWIN applications without breaking those applications.

Katana コンポーネントの概要Getting Started with Katana Components

初めて導入された、1 つの側面、 Node.jsのユーザーの注意をすぐに描画したフレームワークが、簡潔さを作成および Web サーバーを実行する 1 つでした。When it was first introduced, one aspect of the Node.js framework that immediately drew people's attention was the simplicity with which one could author and run a Web server. Katana の目標は、light のフレーム化された場合Node.jsを要約言っておきたい Katana に多くのメリットがもたらされているいずれかの可能性がありますNode.js (と同じように、フレームワーク) スローする開発者を強制することがなくすべての ASP.NET Web アプリケーションの開発について知っています。If Katana goals were framed in light of Node.js, one might summarize them by saying that Katana brings many of the benefits of Node.js (and frameworks like it) without forcing the developer to throw out everything she knows about developing ASP.NET Web applications. このステートメントが true を保持するには、Katana プロジェクトの概要は、均等に単純に本質的にNode.jsします。For this statement to hold true, getting started with the Katana project should be equally simple in nature to Node.js.

"Hello World!"を作成します。Creating "Hello World!"

JavaScript および .NET 開発の大きな違いの 1 つは、(が存在するか)、コンパイラのです。One notable difference between JavaScript and .NET development is the presence (or absence) of a compiler. そのため、単純な Katana サーバーの開始点は、Visual Studio プロジェクトです。As such, the starting point for a simple Katana server is a Visual Studio project. ただし、プロジェクトの種類の中で最も最小限で始めることができます。 空の ASP.NET Web アプリケーション。However, we can start with the most minimal of project types: the Empty ASP.NET Web Application.

次に、インストールしますが、 Microsoft.Owin.Host.SystemWeb NuGet パッケージをプロジェクトにします。Next, we will install the Microsoft.Owin.Host.SystemWeb NuGet package into the project. このパッケージは、ASP.NET の要求パイプラインで実行されている OWIN サーバーを提供します。This package provides an OWIN server that runs in the ASP.NET request pipeline. は、 NuGet ギャラリーと Visual Studio パッケージ マネージャー ダイアログまたはパッケージ マネージャー コンソールのいずれかを次のコマンドを使用してインストールできます。It can be found on the NuGet gallery and can be installed using either the Visual Studio package manager dialog or the package manager console with the following command:

install-package Microsoft.Owin.Host.SystemWeb

インストール、Microsoft.Owin.Host.SystemWebパッケージは依存関係としていくつか追加のパッケージをインストールします。Installing the Microsoft.Owin.Host.SystemWeb package will install a few additional packages as dependencies. これらの依存関係の 1 つはMicrosoft.Owin、いくつかのヘルパー型および OWIN アプリケーションを開発するためのメソッドを提供するライブラリ。One of those dependencies is Microsoft.Owin, a library which provides several helper types and methods for developing OWIN applications. 次のような"hello world"サーバーに迅速にこれらの型を使用できます。We can use those types to quickly write the following "hello world" server.

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

この非常に単純な Web サーバーは、Visual Studio を使用して実行するようになりましたことができますF5コマンドし、デバッグを完全にサポートが含まれています。This very simple Web server can now be run using Visual Studio's F5 command and includes full support for debugging.

ホストの切り替えSwitching hosts

既定では、"hello world"の前の例は、IIS のコンテキストで System.Web を使用して、ASP.NET 要求パイプラインで実行されます。By default, the previous "hello world" example runs in the ASP.NET request pipeline, which uses System.Web in the context of IIS. これを単独で追加できます非常に高い価値の柔軟性と管理機能を OWIN パイプラインの構成可能性と IIS の全体的な成熟度を利用することができます。This can by itself add tremendous value as it enables us to benefit from the flexibility and composability of an OWIN pipeline with the management capabilities and overall maturity of IIS. ただし、IIS で提供される特典は必要ありませんより小さなより軽量なホストは、ある場合があります。However, there may be cases where the benefits provided by IIS are not required and the desire is for a smaller, more lightweight host. 必要なものを次に、IIS や System.Web の外部で単純な Web サーバーを実行しますか。What is needed, then, to run our simple Web server outside of IIS and System.Web?

移植性の目標を示すために、コマンド ライン ホストを Web サーバー ホストから移動、プロジェクトの出力フォルダーに新しいサーバーとホストの依存関係を追加するだけとホストを開始してが必要です。To illustrate the portability goal, moving from a Web-server host to a command line host requires simply adding the new server and host dependencies to project's output folder and then starting the host. この例では、Web サーバーと呼ばれる Katana ホストでホストされますOwinHost.exeKatana HttpListener ベースのサーバーを使用するとします。In this example, we'll host our Web server in a Katana host called OwinHost.exe and will use the Katana HttpListener-based server. 同様に、他の Katana コンポーネントをこれらは、次のコマンドを使用して NuGet から取得したするは。Similarly to the other Katana components, these will be acquired from NuGet using the following command:

install-package OwinHost

コマンドラインからプロジェクトのルート フォルダーに移動し、実行するだけです、 OwinHost.exe (がインストールされている各 NuGet パッケージの [ツール] フォルダーで)。From the command line, we can then navigate to the project root folder and simply run the OwinHost.exe (which was installed in the tools folder of its respective NuGet package). 既定では、OwinHost.exeが HttpListener ベースのサーバーを探すように構成されているため、追加の構成は必要ありません。By default, OwinHost.exe is configured to look for the HttpListener-based server and so no additional configuration is needed. Web ブラウザーでの移動http://localhost:5000/コンソールから実行されているアプリケーションを示しています。Navigating in a Web browser to http://localhost:5000/ shows the application now running through the console.

Katana のアーキテクチャKatana Architecture

Katana のコンポーネント アーキテクチャは、次のようにアプリケーションを 4 つの論理層を分割:ホスト、サーバー、ミドルウェア、アプリケーションします。The Katana component architecture divides an application into four logical layers, as depicted below: host, server, middleware, and application. コンポーネントのアーキテクチャは、方法をこれらのレイヤーの実装に簡単に代わりに使用できる、多くの場合、アプリケーションの再コンパイルせずに考慮されます。The component architecture is factored in such a way that implementations of these layers can be easily substituted, in many cases, without requiring recompilation of the application.


ホストが責任を負います。The host is responsible for:

  • 基になるプロセスを管理します。Managing the underlying process.

  • ワークフローでは、どの要求を OWIN パイプラインの構築と、サーバーの選択、結果を調整することが処理されます。Orchestrating the workflow that results in the selection of a server and the construction of an OWIN pipeline through which requests will be handled.

    現時点では、Katana ベース アプリケーション用の 3 つのプライマリ ホスティング オプションがあります。At present, there are 3 primary hosting options for Katana-based applications:

IIS/ASP.NET:OWIN パイプラインは HttpModule と HttpHandler の標準的な型を使用して、ASP.NET 要求フローの一部として IIS で実行できます。IIS/ASP.NET: Using the standard HttpModule and HttpHandler types, OWIN pipelines can run on IIS as a part of an ASP.NET request flow. ASP.NET ホストのサポートは、Web アプリケーション プロジェクトに Microsoft.AspNet.Host.SystemWeb NuGet パッケージのインストールで有効です。ASP.NET hosting support is enabled by installing the Microsoft.AspNet.Host.SystemWeb NuGet package into a Web application project. さらに、IIS は、ホストとサーバーの両方として動作するための SystemWeb ホストを使用する場合、開発者によって、別のサーバー実装を置き換えることはできませんので、この NuGet パッケージで OWIN サーバー/ホストの違いが結び付いています。Additionally, because IIS acts as both a host and a server, the OWIN server/host distinction is conflated in this NuGet package, meaning that if using the SystemWeb host, a developer cannot substitute an alternate server implementation.

カスタム ホスト:Katana コンポーネント スイートによってで開発者は、コンソール アプリケーション、Windows サービスなどがあるかどうか自分のカスタムのプロセスでアプリケーションをホストできます。この機能は、Web API によって提供される自己ホスト機能に似ています。Custom Host: The Katana component suite gives a developer the ability to host applications in her own custom process, whether that is a console application, Windows service, etc. This capability looks similar to the self-host capability provided by Web API. 次の例は、Web API コードのカスタム ホストを示しています。The following example shows a custom host of Web API code:

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))
        Console.WriteLine("Press Enter to quit.");

Katana アプリケーションの自己ホストのセットアップは似ています。The self-host setup for a Katana application is similar:

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.");

Web API と Katana の自己ホスト例の 1 つの大きな違いは、Web API の構成コードが Katana の自己ホスト例から不足していることです。One notable difference between the Web API and Katana self-host examples is that the Web API configuration code is missing from the Katana self-host example. 移植性と構成可能性の両方を有効にするためには、Katana は、要求処理パイプラインを構成するコードからサーバーを起動するコードを分離します。In order to enable both portability and composability, Katana separates the code that starts the server from the code that configures the request processing pipeline. Web API を構成するコードは、WebApplication.Start で型パラメーターとして指定されたさらに、スタートアップ クラスに含まれます。The code that configures Web API, then is contained in the class Startup, which is additionally specified as the type parameter in WebApplication.Start.

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

スタートアップ クラスについては、記事の後半で詳しく説明します。The startup class will be discussed in greater detail later in the article. ただし、コードは、自己ホスト プロセスは自己ホスト アプリケーションの ASP.NET Web API で今すぐ使用する場合のコードに非常に似て Katana を開始する必要があります。However, the code required to start a Katana self-host process looks strikingly similar to the code that you may be using today in ASP.NET Web API self-host applications.

OwinHost.exe:Katana の Web アプリケーションを実行するカスタム プロセスを記述する必要があるいくつかが、中に多くを希望するサーバーを起動して、アプリケーションを実行できるビルド済み実行可能ファイルを起動するだけです。OwinHost.exe: While some will want to write a custom process to run Katana Web applications, many would prefer to simply launch a pre-built executable that can start a server and run their application. このシナリオでは、Katana コンポーネントのスイートが含まれていますOwinHost.exeします。For this scenario, the Katana component suite includes OwinHost.exe. プロジェクトのルート ディレクトリ内から実行する、この実行可能ファイルは (サーバーを使用して、HttpListener 既定で) サーバーを起動し、規則を使用して検索し、ユーザーの startup クラスを実行します。When run from within a project's root directory, this executable will start a server (it uses the HttpListener server by default) and use conventions to find and run the user's startup class. 実行可能ファイルより細かな制御には、多数の追加のコマンド ライン パラメーターを提供します。For more granular control, the executable provides a number of additional command line parameters.


ホストが開始すると、プロセスをアプリケーションを実行するサーバーの役割を維持するネットワーク ソケットを開き、要求をリッスンして OWIN コンポーネントのパイプラインを使用して送信で指定された (とするユーザー既に気付いたかもしれませんが、このパイプラインは、アプリケーション開発者の Startup クラスで指定)。While the host is responsible for starting and maintaining process within which the application runs, the responsibility of the server is to open a network socket, listen for requests, and send them through the pipeline of OWIN components specified by the user (as you may have already noticed, this pipeline is specified in the application developer's Startup class). 現時点では、Katana プロジェクトには、2 つのサーバー実装が含まれています。Currently, the Katana project includes two server implementations:

  • Microsoft.Owin.Host.SystemWeb:既に触れましたが、IIS ホストとサーバーの両方として ASP.NET パイプラインの機能と連携します。Microsoft.Owin.Host.SystemWeb: As previously mentioned, IIS in concert with the ASP.NET pipeline acts as both a host and a server. そのため、ホスト オプションこれを選択するときに IIS プロセスのアクティブ化などのホスト レベルの懸案事項の管理し、の両方が HTTP 要求をリッスンします。Therefore, when choosing this hosting option, IIS both manages host-level concerns such as process activation and listens for HTTP requests. ASP.NET Web アプリケーションの場合はその後、ASP.NET パイプラインに要求を送信します。For ASP.NET Web applications, it then sends the requests into the ASP.NET pipeline. Katana SystemWeb ホストは、HTTP パイプラインを通過し、ユーザー指定の OWIN パイプラインを使用して送信要求をインターセプトするには、ASP.NET HttpModule と HttpHandler を登録します。The Katana SystemWeb host registers an ASP.NET HttpModule and HttpHandler to intercept requests as they flow through the HTTP pipeline and send them through the user-specified OWIN pipeline.
  • Microsoft.Owin.Host.HttpListener:名前が示すとおり、この Katana サーバーは、ソケットを開くし、開発者が指定した OWIN パイプラインに要求を送信する .NET Framework の HttpListener クラスを使用します。Microsoft.Owin.Host.HttpListener: As its name indicates, this Katana server uses the .NET Framework's HttpListener class to open a socket and send requests into a developer-specified OWIN pipeline. これは、現在、Katana 自己ホスト API と OwinHost.exe の既定のサーバーの選択です。This is currently the default server selection for both the Katana self-host API and OwinHost.exe.


前述のように、サーバーがクライアントからの要求を受け入れるときを担当の開発者のスタートアップ コードで指定された OWIN コンポーネントは、パイプラインを介して渡すことです。As previously mentioned, when the server accepts a request from a client, it is responsible for passing it through a pipeline of OWIN components, which are specified by the developer's startup code. これらのパイプライン コンポーネントは、ミドルウェアと呼ばれます。These pipeline components are known as middleware.
非常に基本的なレベルで、OWIN ミドルウェア コンポーネントは呼び出しができるように、OWIN アプリケーション デリゲートを実装するだけで済みます。At a very basic level, an OWIN middleware component simply needs to implement the OWIN application delegate so that it is callable.

Func<IDictionary<string, object>, Task>

ただし、開発とミドルウェア コンポーネントの構成を簡素化するために Katana をいくつかの規則とヘルパー型のサポートのミドルウェア コンポーネントします。However, in order to simplify the development and composition of middleware components, Katana supports a handful of conventions and helper types for middleware components. これらの最も一般的な状況は、OwinMiddlewareクラス。The most common of these is the OwinMiddleware class. このクラスを使用して構築されたカスタムのミドルウェア コンポーネントは、次のようになります。A custom middleware component built using this class would look similar to the following:

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");

このクラスから派生OwinMiddleware、実装、コンス トラクターを引数の 1 つとして、パイプラインの次のミドルウェアのインスタンスを受け取り、基本コンス トラクターに渡されます。This class derives from OwinMiddleware, implements a constructor that accepts an instance of the next middleware in the pipeline as one of its arguments, and then passes it to the base constructor. ミドルウェアを構成するために使用する追加の引数は、次のミドルウェア パラメーターの後にもコンス トラクターのパラメーターとして宣言されます。Additional arguments used to configure the middleware are also declared as constructor parameters after the next middleware parameter.

ミドルウェアの実行時に、使用して、オーバーライドされたInvokeメソッド。At runtime, the middleware is executed via the overridden Invoke method. このメソッドは、型の 1 つの引数を受け取りますOwinContextします。This method takes a single argument of type OwinContext. このコンテキスト オブジェクトは、によって提供される、 Microsoft.Owin NuGet パッケージを選択し、前に説明したいくつかの追加のヘルパー型と共に、要求、応答、および環境のディクショナリに厳密に型指定されたアクセスを提供します。This context object is provided by the Microsoft.Owin NuGet package described earlier and provides strongly-typed access to the request, response and environment dictionary, along with a few additional helper types.

ミドルウェア クラスに簡単に追加できますアプリケーションのスタートアップ コードで OWIN パイプラインにとおり。The middleware class can be easily added to the OWIN pipeline in the application startup code as follows:

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


ミドルウェア コンポーネントの単純なものから複雑性の範囲は Katana インフラストラクチャは、単に、OWIN ミドルウェア コンポーネントのパイプラインを構築し、単にコンポーネントをパイプラインに参加するアプリケーション デリゲートをサポートする必要があるため、ASP.NET Web API などの全体のフレームワークにロガーまたはSignalRします。Because the Katana infrastructure simply builds up a pipeline of OWIN middleware components, and because the components simply need to support the application delegate to participate in the pipeline, middleware components can range in complexity from simple loggers to entire frameworks like ASP.NET, Web API, or SignalR. たとえば、前の OWIN パイプラインへの ASP.NET Web API の追加には、次のスタートアップ コードを追加する必要があります。For example, adding ASP.NET Web API to the previous OWIN pipeline requires adding the following startup code:

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

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

      // additional middleware registrations            

Katana インフラストラクチャでは、構成方法の IAppBuilder オブジェクトに追加された順序に基づくミドルウェア コンポーネントのパイプラインを作成します。The Katana infrastructure will build the pipeline of middleware components based on the order in which they were added to the IAppBuilder object in the Configuration method. この例では、LoggerMiddleware 処理できる最終的にそれらの要求が処理される方法に関係なく、パイプラインを通過するすべての要求。In our example, then, LoggerMiddleware can handle all requests that flow through the pipeline, regardless of how those requests are ultimately handled. これにより、強力なシナリオのミドルウェア コンポーネント (例: 認証コンポーネント) が複数のコンポーネントやフレームワーク (ASP.NET Web API、SignalR、および静的なファイル サーバーなど) を含むパイプラインの要求を処理できます。This enables powerful scenarios where a middleware component (e.g. an authentication component) can process requests for a pipeline that includes multiple components and frameworks (e.g. ASP.NET Web API, SignalR, and a static file server).


前の例に示すよう、OWIN と Katana プロジェクトいないと考えられますがの新しいアプリケーション プログラミング モデルはアプリケーション プログラミング モデルとサーバーとホスト インフラストラクチャからフレームワークを分離するために抽象化としてではなく。As illustrated by the previous examples, OWIN and the Katana project should not be thought of as a new application programming model, but rather as an abstraction to decouple application programming models and frameworks from server and hosting infrastructure. たとえば、Web API アプリケーションを構築するときに開発者フレームワークは引き続き、Katana プロジェクトからコンポーネントを使用して、OWIN パイプラインでアプリケーションを実行するかどうかに関係なく、ASP.NET Web API フレームワークを使用します。For example, when building Web API applications, the developer framework will continue to use the ASP.NET Web API framework, irrespective of whether or not the application runs in an OWIN pipeline using components from the Katana project. OWIN に関連するコードは、アプリケーション開発者に示される 1 つの場所が、開発者が、OWIN パイプラインを作成、アプリケーションのスタートアップ コードでになります。The one place where OWIN-related code will be visible to the application developer will be the application startup code, where the developer composes the OWIN pipeline. スタートアップ コードで、開発者は、一連の受信要求を処理する各ミドルウェア コンポーネントのいずれかの一般的に UseXx ステートメントを登録します。In the startup code, the developer will register a series of UseXx statements, generally one for each middleware component that will process incoming requests. このエクスペリエンスは、System.Web の現在の世界では、HTTP モジュールを登録すると同じ効果があります。This experience will have the same effect as registering HTTP modules in the current System.Web world. 通常より大きな framework などのミドルウェア、ASP.NET Web API またはSignalRパイプラインの最後に登録されます。Typically, a larger framework middleware, such as ASP.NET Web API or SignalR will be registered at the end of the pipeline. 認証や、キャッシュなどの横断ミドルウェア コンポーネントは、フレームワークと、パイプラインの後半で登録されているコンポーネントのすべての要求を処理するように、通常、パイプラインの先頭に向かって登録されます。Cross-cutting middleware components, such as those for authentication or caching, are generally registered towards the beginning of the pipeline so that they will process requests for all of the frameworks and components registered later in the pipeline. この分離ミドルウェア コンポーネントの基になるインフラストラクチャ コンポーネントとの相互からは、システム全体の安定状態が保たを確保しながら、さまざまな速度で進化するコンポーネントを使用できます。This separation of the middleware components from each other and from the underlying infrastructure components enables the components to evolve at different velocities while ensuring that the overall system remains stable.

コンポーネント – NuGet パッケージComponents – NuGet Packages

多数の現在のライブラリおよびフレームワークのように、Katana プロジェクト コンポーネントは、一連の NuGet パッケージとして配信されます。Like many current libraries and frameworks, the Katana project components are delivered as a set of NuGet packages. 今後のバージョン 2.0、Katana パッケージの依存関係グラフは次のとおりです。For the upcoming version 2.0, the Katana package dependency graph looks as follows. (画像が拡大表示をクリックします。)(Click on image for larger view.)

Katana プロジェクト内のほぼすべてのパッケージによって異なります、直接または間接的に、Owin パッケージ。Nearly every package in the Katana project depends, directly or indirectly, on the Owin package. OWIN 仕様のセクション 4 で説明されているアプリケーションの起動処理の具象実装を提供する IAppBuilder インターフェイスが含まれるパッケージであること。You may remember that this is the package that contains the IAppBuilder interface, which provides a concrete implementation of the application startup sequence described in section 4 of the OWIN specification. さらに、パッケージの多くは、HTTP 要求と応答を操作するための一連のヘルパー型を提供する Microsoft.Owin に依存します。Additionally, many of the packages depend on Microsoft.Owin, which provides a set of helper types for working with HTTP requests and responses. パッケージの残りの部分は、ホスティング インフラストラクチャ パッケージ (サーバーまたはホスト) またはミドルウェアのいずれかとして分類することができます。The remainder of the package can be classified as either hosting infrastructure packages (servers or hosts) or middleware. パッケージと Katana プロジェクトの外部の依存関係は、オレンジ色で表示されます。Packages and dependencies that are external to the Katana project are displayed in orange.

Katana 2.0 のホスティング インフラストラクチャの SystemWeb と HttpListener ベースのサーバー、OwinHost.exe を使用して、OWIN アプリケーションの実行に OwinHost パッケージと Microsoft.Owin.Hosting パッケージでの OWIN アプリケーションを自己ホストの両方を含む、カスタム ホスト (例: コンソール アプリケーション、Windows サービスなど)The hosting infrastructure for Katana 2.0 includes both the SystemWeb and HttpListener-based servers, the OwinHost package for running OWIN applications using OwinHost.exe, and the Microsoft.Owin.Hosting package for self-hosting OWIN applications in a custom host (e.g. console application, Windows service, etc.)

Katana 2.0 のミドルウェア コンポーネントは主に異なる認証方法を提供します。For Katana 2.0, the middleware components are primarily focused on providing different means of authentication. 開始し、エラー ページのサポートを有効にする診断の 1 つの追加のミドルウェア コンポーネントが提供されます。One additional middleware component for diagnostics is provided, which enables support for a start and error page. OWIN が事実上のホスティングの抽象化になるにつれて、ミドルウェア コンポーネントは、Microsoft とサード パーティによって開発されたもの両方のエコシステムも数に大きくなります。As OWIN grows into the de facto hosting abstraction, the ecosystem of middleware components, both those developed by Microsoft and third parties, will also grow in number.


作成し、それによってにより開発者はさらに別の Web フレームワークについて説明しますが、の先頭から Katana プロジェクトの目標をされていません。From its beginning, the Katana project's goal has not been to create and thereby force developers to learn yet another Web framework. 代わりに、目標は以前よりも可能な多くの選択肢を .NET Web アプリケーションの開発者に提供する抽象化を作成するようにしています。Rather, the goal has been to create an abstraction to give .NET Web application developers more choice than has previously been possible. 置き換え可能なコンポーネントのセットに一般的な Web アプリケーション スタックの論理層を分割しては、Katana プロジェクトは、これらのコンポーネントの意味がどのような比率で向上させるために、スタック全体のコンポーネントを使用できます。By breaking up the logical layers of a typical Web application stack into a set of replaceable components, the Katana project enables components throughout the stack to improve at whatever rate makes sense for those components. 簡単な OWIN 抽象化の周りのすべてのコンポーネントを構築することにより Katana によりフレームワークおよびさまざまな別のサーバーとホスト間で移植できる基盤に構築されたアプリケーションを使用できます。By building all components around the simple OWIN abstraction, Katana enables frameworks and the applications built on top of them to be portable across a variety of different servers and hosts. スタックのコントロールには、開発者を配置すること、Katana を行うことにより、開発者がどのように軽量の ultimate の選択を行ったことか、機能豊富などのように自分の Web スタックがする必要があります。By putting the developer in control of the stack, Katana ensures that the developer makes the ultimate choice about how lightweight or how feature-rich her Web stack should be.

Katana の詳細についてはFor more information about Katana