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層：
下面是一個比較簡略的圖例：
如果拋開所有重量級，企業級需求不談，我們返璞歸真，可以這樣理解這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能夠有更加深入的理解和思考
