OWIN的理解和實踐(一) – 解耦,協作和開放


概述

OWIN的全稱是Open Web Interface For .Net, 是MS在VS2013期間引入的全新的概念, 網上已經有不少的關於它的信息, 這里我就談下我自己的理解:

  • OWIN是一種規范和標准, 不代表特定技術. MS最新出現的一些新的技術, 比如Kanata, Identity, SignalR, 它們只是基於OWIN的不同實現, 這個在以后章節會進一步討論.
  • OWIN的核心理念是解耦,協作和開放---這和MS以前的風格大相徑庭,值得引起大家的注意。
  • OWIN是MS未來Web開發的方向,想跟着MS路線繼續開發Web應用,OWIN是大勢所趨。

4層理念

說到解耦,一個比較明確的理念是,OWIN吧一個Web應用的解決方案解耦為4層:

  • Host: 宿主
  • Server: 服務器
  • Middleware: 中間件
  • Application: 具體應用

下面是一個比較簡略的圖例:

 

如果拋開所有重量級,企業級需求不談,我們返璞歸真,可以這樣理解這4層:

  • Host: 應用程序的主進程,主要負責啟動,關閉Server,為Server加載各種Middleware組件,當然同時也裝載Application.
  • Server: 一般來說,我們的Web應用還是基於HTTP協議來開發的,而這里的Server其本質就是一個空殼的Http Server,監聽端口,接收Http Request,返回Http Response,不過,如果沒有任何中間件的參與,我們應該認為,Server只會返回一個空的Response給請求者而已。
  • Middleware: 裝載在在Server中的Middleware提供各種功能, 處理Request, 然后通過某種方式, 返回Reponses.當然, 某些Middleware也可以不返回任何Response, 而僅僅是做內部處理, 比如實現Session的Middleware.
  • Application: 開發者真正關注的業務系統內容, Reponses中真正業務內容的提供者.

意義和遠景

下面提下OWIN對我們未來Web開發帶來的變化,來幫助我們進一步理解這個規范的意義:

  • OWIN規則使得各層能夠解耦, 我們完全可以把Host, Server, Middleware 和Application交給不同的開發者來完成, 然后完成整合.
  • 只要基於同一的OWIN的標准,各層間不同實現的協作更加便利,比如,除Application層必須自行開發以外, Host我們可以選擇IIS, 也可以選擇任何進程,包括在Mono支持下的其他操作系統的進程; Server目前有MS的Kanata ,Linux上的Jexus; 而Middleware則有更加廣泛的選擇,MS已經提供的WebApi, Identity, SignalR都已經是基於OWIN標准的中間件實現, 可以預見以后將有大量的第三方實現紛至沓來.
  • 整個系統的實現更開放,目前大部分的OWIN實現都是獨立而且開源的,開發團隊可以根據自身項目的需要和技術特點,自行開發或者改造Host, Server或者Middleware, 而在一些不重要或者不擅長的場合選用第三方提供的實現.

 

目前來看,基於OWIN的整體解決方案尚未完全展開,而MS也將在下一代ASP.Net vNext版本中才能最終完善OWIN體系的實現.

        不過, 基於OWIN標准的先行者的Kanata項目,目前已經到3.0.1版本,其中已經對Host - Hosting, Server – HttpListener, 靜態文件系統 - Static Files , 日志 - Logging,安全和權限系統 -  Security, 錯誤跟蹤 – Diagnostics 有了相當規模的實現, 而大家耳熟能詳的WebApi組件則早以和老朋友System.Web解耦,加入了OWIN的陣營. 另外,在OWIN框架下,開發者完全可以開發和架設自己的組件來滿足實際的需求,以此看來,OWIN的解決方案其實已經初具雛形.

所以基於上面這些技術,下面我會進一步對Host, Server, Middleware, Application的一些具體實現進行一些討論,以幫助大家對OWIN能夠有更加深入的理解和思考


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM