프로젝트 Katana 개요An Overview of Project Katana

Howard Dierkingby Howard Dierking

ASP.NET 프레임 워크는 10 년 이상 사용 되었으며 플랫폼은 수많은 웹 사이트 및 서비스의 개발을 지원 합니다.The ASP.NET Framework has been around for over ten years, and the platform has enabled the development of countless Web sites and services. 웹 응용 프로그램 개발 전략이 발전 함에 따라 프레임 워크는 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. 웹 응용 프로그램 개발에서 클라우드 컴퓨팅 세계에 대 한 다음 발전 단계를 수행 하기 때문에 project Katana 는 ASP.NET 응용 프로그램에 대 한 기본 구성 요소 집합을 제공 하 여 유연 하 고 이식 가능 하며 경량 이며 더 나은 성능을 제공할 수 있습니다. 다른 방법으로 project Katana cloud는 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는 원래 두 명의 고객과 함께 만들어졌습니다.ASP.NET was originally created with two customers in mind.

고객의 첫 번째 그룹은 기본 ASP 개발자 였습니다.The first group of customers was classic ASP developers. 당시 ASP는 태그 및 서버 쪽 스크립트를 interweaving 하 여 동적 데이터 기반 웹 사이트 및 응용 프로그램을 만들기 위한 기본 기술 중 하나 였습니다.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. 기본 HTTP 프로토콜 및 웹 서버의 핵심 측면을 추상화 하 고 세션 및 응용 프로그램 상태 관리, 캐시 등의 추가 서비스에 대 한 액세스를 제공 하는 개체 집합을 제공 하는 ASP 런타임은 서버 쪽 스크립트를 제공 합니다. 강력 하지만 기존 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는 개체 지향 언어에서 제공 하는 코드 조직을 활용 하는 동시에 서버 쪽 프로그래밍 모델도 유지 합니다. 기존 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에 대 한 대상 고객의 두 번째 그룹은 Windows 비즈니스 응용 프로그램 개발자 였습니다.The second group of target customers for ASP.NET was Windows business application developers. HTML 태그를 작성 하 고 html 태그를 생성 하는 코드를 작성 하는 데 익숙한 기존 ASP 개발자와는 달리 WinForms 개발자 (이전에는 VB6 개발자)가 캔버스와 풍부한 사용자 집합을 포함 하는 디자인 타임 환경에 익숙합니다. 인터페이스 컨트롤.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. WinForms 개발자에 게 친숙 한 상태 저장 이벤트 모델에서 웹의 상태 비저장 특성을 효과적으로 hid Web Forms 합니다.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. 첫째, 프레임 워크는 논리적으로 서로 다른 기능 단위를 동일한 모놀리식어셈블리 (예: web forms 프레임 워크를 사용 하는 핵심 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 하는 데 어려움이 있었습니다.This made it difficult for ASP.NET to keep pace with all of the changes happening in rapidly evolving Web development. 마지막으로, System.web .dll 자체는 특정 웹 호스팅 옵션인 인터넷 정보 서비스 (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

웹 개발에서 많은 변화가 있었습니다.And lots of change was happening in Web development! 웹 응용 프로그램은 점점 더 많은 프레임 워크가 아닌 일련의 작고 집중 된 구성 요소로 개발 되 고 있습니다.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. 웹을 사용 하는 데는 더 크고 더 많은 기능을 제공 하는 것이 아니라 더 작은 기능을 제공 하는 프레임 워크가 필요 합니다. 따라서 ASP.NET 팀은 단일 프레임 워크가 아닌 플러그형 웹 구성 요소 제품군으로 ASP.NET을 사용 하기 위한 여러 가지 혁신적인 단계를 수행했습니다.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.

초기 변경 내용 중 하나는 Ruby의 Ruby와 같은 웹 개발 프레임 워크 덕분에 잘 알려진 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. 이러한 웹 응용 프로그램 빌드 스타일을 통해 개발자는 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. 이러한 스타일의 웹 응용 프로그램 개발에 대 한 수요를 충족 하기 위해 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.

웹 응용 프로그램 개발의 또 다른 주요 변화는 AJAX 요청을 통해 백 엔드 웹 api와통신 하는 클라이언트 쪽 스크립트에서 생성 된 페이지의 동적 섹션을 사용 하 여 서버에서 생성 된 동적 웹 페이지에서 정적 초기 태그로의 이동 이었습니다.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. 이 아키텍처 시프트는 웹 Api의 propel 및 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. 엔지니어링 팀이 기회 및 빌드 ASP.NET Web API를 활용 하 여 system.web에서 찾은 핵심 프레임 워크 형식에 종속 되지 않도록 했습니다.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. 이 기능을 사용 하도록 설정 하는 두 가지 작업이 있습니다. 첫 번째는 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). 둘째, System.web에 대 한 외부 종속성이 없으므로 IIS에 대 한 종속성이 없으므로 사용자 지정 호스트에서 실행할 수 있는 기능 (예: 콘솔 응용 프로그램, Windows 서비스 등)이 포함 ASP.NET Web API.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

프레임 워크 구성 요소를 다른 구성 요소에서 분리 한 다음 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. 최신 웹 응용 프로그램은 일반적으로 정적 파일 처리, 동적 페이지 생성, 웹 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.

OWIN (Open Web Interface for .NET)The Open Web Interface for .NET (OWIN)

Ruby 커뮤니티의 랙에 의해 제공 되는 혜택을 통해 .net 커뮤니티의 여러 멤버가 웹 서버와 프레임 워크 구성 요소 간의 추상화를 만들도록 설정 했습니다.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 추상화에 대 한 두 가지 디자인 목표는 간단 하 고 다른 프레임 워크 형식에 대해 가능한 최소한의 종속성을 가져왔습니다.Two design goals for the OWIN abstraction were that it was simple and that it took the fewest possible dependencies on other framework types. 이러한 두 가지 목표는 다음을 확인 하는 데 도움이 됩니다.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.

결과 추상화는 두 개의 핵심 요소로 구성 됩니다.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 호환 웹 서버는 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 사양은 코어 사전 키 값 쌍의 목록을 정의 합니다.In addition to specifying the type for the environment dictionary, the OWIN specification defines a list of core dictionary key value pairs. 예를 들어 다음 표에는 HTTP 요청에 대 한 필수 사전 키가 나와 있습니다.For example, the following table shows the required dictionary keys for an HTTP request:

키 이름Key Name 값 설명Value Description
"owin.RequestBody" 요청 본문 (있는 경우)을 포함 하는 스트림입니다.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" 요청에 대 한 HTTP 요청 메서드 (예: "GET", "POST")를 포함 하는 string입니다.A string containing the HTTP request method of the request (e.g., "GET", "POST").
"owin.RequestPath" 요청 경로를 포함 하는 string입니다.A string containing the request path. 경로는 응용 프로그램 대리자의 "루트"에 상대적 이어야 합니다. 경로를 참조 하세요.The path MUST be relative to the "root" of the application delegate; see Paths.
"owin.RequestPathBase" 응용 프로그램 대리자의 "루트"에 해당 하는 요청 경로의 일부를 포함 하는 string입니다. 경로를 참조 하세요.A string containing the portion of the request path corresponding to the "root" of the application delegate; see Paths.
"owin.RequestProtocol" 프로토콜 이름 및 버전이 포함 된 string (예: "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" 앞에 "?"가 없는 HTTP 요청 URI의 쿼리 문자열 구성 요소가 포함 된 string (예: "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" 요청에 사용 되는 URI 체계를 포함 하는 string (예: "http", "https") URI 체계를 참조 하세요.A string containing the URI scheme used for the request (e.g., "http", "https"); see URI Scheme.

OWIN의 두 번째 주요 요소는 응용 프로그램 대리자입니다.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). 그 목표는 다음 웹 프레임 워크가 아니라 웹 프레임 워크와 웹 서버가 상호 작용 하는 방식에 대 한 사양입니다.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도 확인할 수 있습니다.If you've investigated OWIN or Katana, you may also have noticed the Owin NuGet package and Owin.dll. 이 라이브러리에는 OWIN 사양의 4 단원 에 설명 된 시작 시퀀스를 공식화 하 고 체계화 하는 iappbuilder의 단일 인터페이스가 포함 되어 있습니다.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 는 모두 커뮤니티 소유 이며 커뮤니티에서 오픈 소스를 실행 하는 반면, Katana 프로젝트는 오픈 소스에서 MICROSOFT가 빌드하고 출시 하는 OWIN 구성 요소 집합을 나타냅니다.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 Web API같은 프레임 워크에 대 한 바인딩 구성 요소와 같은 기능 구성 요소가 포함 됩니다.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. 프로젝트에는 다음과 같은 세 가지 높은 수준의 목표가 있습니다.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 서버에서 원활 하 게 실행 될 수 있는 반면 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. 또한 하위 수준 구성 요소의 substitutability는 사용할 수 있게 되 면 새로운 고성능 서버를 원활 하 게 도입 하 여 응용 프로그램을 손상 시 키 지 않고 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

처음 도입 된 경우, 사용자의 주의가 즉시 제공 되는 node.js 프레임 워크의 한 가지 측면은 웹 서버를 작성 하 고 실행할 수 있는 단순성 이었습니다.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 목표가 node.js에 포함 된 경우 개발자가 ASP.NET 웹 응용 프로그램 개발에 대해 알고 있는 모든 것을 강제로 제공 하지 않고도 Katana (및 이와 유사한 프레임 워크)의 많은 이점을 제공 한다는 것을 설명 하 여이를 요약할 수 있습니다.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 개발의 중요 한 차이점 중 하나는 컴파일러의 존재 여부입니다.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 웹 응용 프로그램의 프로젝트 형식 중에서 가장 적은 작업을 시작할 수 있습니다.However, we can start with the most minimal of project types: the Empty ASP.NET Web Application.

다음에는 Owin 웹 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. 이러한 종속성 중 하나는 OWIN 응용 프로그램을 개발 하기 위한 몇 가지 도우미 형식 및 메서드를 제공 하는 라이브러리인 Microsoft.Owin입니다.One of those dependencies is Microsoft.Owin, a library which provides several helper types and methods for developing OWIN applications. 이러한 형식을 사용 하 여 다음 "hello 세계" 서버를 신속 하 게 작성할 수 있습니다.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!");
      });
   }
}

이제 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 세계" 예제는 IIS의 컨텍스트에서 System.web를 사용 하는 ASP.NET request 파이프라인에서 실행 됩니다.By default, the previous "hello world" example runs in the ASP.NET request pipeline, which uses System.Web in the context of IIS. 이는 자체를 사용 하 여 OWIN 파이프라인의 유연성과 composability에서 관리 기능 및 전체 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 외부에서 간단한 웹 서버를 실행 하려면 어떻게 해야 하나요?What is needed, then, to run our simple Web server outside of IIS and System.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. 이 예제에서는 OwinHost.exe 이라는 Katana 호스트에 웹 서버를 호스팅하고 Katana 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 패키지의 tools 폴더에 설치 된)만 실행할 수 있습니다.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. 웹 브라우저에서 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.

호스트Host

호스트는 다음을 담당 합니다.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 기반 응용 프로그램에 대 한 세 가지 기본 호스팅 옵션이 있습니다.At present, there are 3 primary hosting options for Katana-based applications:

Iis/asp.net: 표준 HttpModule 및 HttpHandler 형식을 사용 하 여 OWIN 파이프라인은 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. 웹 응용 프로그램 프로젝트에 Microsoft ASP.NET 웹 NuGet 패키지를 설치 하 여 호스팅 지원을 사용할 수 있습니다.ASP.NET hosting support is enabled by installing the Microsoft.AspNet.Host.SystemWeb NuGet package into a Web application project. 또한 IIS는 호스트 및 서버 역할을 수행 하므로이 NuGet 패키지에 OWIN 서버/호스트의 차이가 있습니다. 즉, SystemWeb 호스트를 사용 하는 경우 개발자는 대체 서버 구현을 대체할 수 없습니다.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))
    {
        svr.OpenAsync().Wait();
        Console.WriteLine("Press Enter to quit.");
        Console.ReadLine();
    }
}

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.");
        Console.ReadKey();
    }
}

Web API와 Katana 자체 호스트 예제에서 주목할 만한 차이점 중 하나는 웹 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. 이식성과 composability를 모두 사용 하기 위해 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}");
        app.UseWebApi(config);
    }
}

시작 클래스는이 문서의 뒷부분에서 자세히 설명 합니다.The startup class will be discussed in greater detail later in the article. 그러나 Katana 자체 호스트 프로세스를 시작 하는 데 필요한 코드는 ASP.NET Web API 자체 호스트 응용 프로그램에서 현재 사용 하 고 있는 코드와 비슷합니다 strikingly.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: 일부는 Katana 웹 응용 프로그램을 실행 하는 사용자 지정 프로세스를 작성 하려고 하지만, 대부분 서버를 시작 하 고 응용 프로그램을 실행할 수 있는 미리 작성 된 실행 파일을 시작 하는 것이 좋습니다.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 서버 사용) 규칙을 사용 하 여 사용자의 시작 클래스를 찾고 실행 합니다.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.

서버Server

호스트는 응용 프로그램이 실행 되는 프로세스의 시작 및 유지 관리를 담당 하는 반면 서버는 네트워크 소켓을 열고, 요청을 수신 하 고, 사용자가 지정한 OWIN 구성 요소의 파이프라인을 통해 전송 하는 것입니다. 이미 알고 있을 수 있습니다 .이 파이프라인은 응용 프로그램 개발자의 시작 클래스에서 지정 됩니다.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 프로젝트에는 두 개의 서버 구현이 포함 되어 있습니다.Currently, the Katana project includes two server implementations:

  • Owin 웹: 앞에서 설명한 것 처럼 ASP.NET 파이프라인과 함께 사용 되는 IIS는 호스트와 서버 역할을 모두 수행 합니다.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 웹 응용 프로그램의 경우 요청을 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.
  • Owin. HttpListener: 이름에 따라이 Katana 서버는 .NET Framework의 HttpListener 클래스를 사용 하 여 소켓을 열고 개발자가 지정한 Owin 파이프라인으로 요청을 보냅니다.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 모두에 대 한 기본 서버 선택입니다.This is currently the default server selection for both the Katana self-host API and OwinHost.exe.

미들웨어/프레임 워크Middleware/framework

앞에서 설명한 것 처럼 서버가 클라이언트의 요청을 수락 하면 개발자의 시작 코드에 지정 된 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에서 파생 되 고, 파이프라인의 다음 미들웨어 인스턴스를 해당 인수 중 하나로 수락한 다음 기본 생성자에 전달 하는 생성자를 구현 합니다.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. 이 메서드는 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 
      app.UseWebApi(config);

      // 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).

애플리케이션Applications

앞의 예제에서 설명한 것 처럼 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. 예를 들어 웹 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 관련 코드가 응용 프로그램 개발자에 게 표시 되는 한 위치는 개발자가 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. 일반적으로 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 요청 및 응답을 사용 하기 위한 도우미 형식 집합을 제공 하는 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 패키지 및에서 자체 호스팅 OWIN 응용 프로그램을 위한 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. 진단을 위한 추가 미들웨어 구성 요소가 하나씩 제공 되며이를 통해 시작 및 오류 페이지를 지원할 수 있습니다.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.

결론Conclusion

처음부터 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 웹 응용 프로그램 개발자에 게 이전에 사용할 수 있는 것 보다 더 많은 옵션을 제공 하는 추상화를 만드는 것이 목표입니다.Rather, the goal has been to create an abstraction to give .NET Web application developers more choice than has previously been possible. 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. Katana는 간단한 OWIN 추상화를 중심으로 모든 구성 요소를 빌드하여 프레임 워크와 프레임 워크를 기반으로 구축 된 응용 프로그램을 다양 한 서버 및 호스트에서 이식할 수 있습니다.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. 개발자가 stack의 제어를 설정 하 여 Katana는 개발자가 기능을 사용 하는 방법에 대 한 최고의 선택 이나 기능을 갖춘 웹 스택이 무엇 인지를 확인 합니다.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

감사의 말Acknowledgements