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能夠有更加深入的了解和思考

軟體開發,項目管理,開發管理,團隊管理.

CMMI,PMP