OWIN– 解耦,协作和开放

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: 具体应用

下面是一个比较简略的图例:

 OWIN– 解耦,协作和开放_第1张图片

如果抛开所有重量级,企业级需求不谈,我们返璞归真,可以这样理解这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
 
 
标签:  ASP.NetWeb开发.NETOWIN

你可能感兴趣的:(.net,web开发,asp.net,Owin)