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

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

如果抛开所有重量级,企业级需求不谈,我们返璞归真,可以这样理解这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能够有更加深入的理解和思考

时间: 2024-08-02 08:23:29

OWIN的理解和实践(一) – 解耦,协作和开放的相关文章

OWIN的理解和实践(二) – Host和Server的开发

原文:OWIN的理解和实践(二) – Host和Server的开发 对于开发人员来说,代码就是最好的文档,如上一篇博文所说,下面我们就会基于Kanata项目的一些具体调用代码,来进一步深入理解OWIN的实现和作用. 今天我们先针对Host和Server来实现一个简单的应用. 我们的开发环境是:  VS2013 Update 3,  .Net Framework 4.5.1 Host开发 如上篇博文提及,Host具有如下特点: 实现一个宿主进程 负责Server的启动和关闭 负责Middlewar

OWIN的理解和实践(三) –Middleware开发入门

原文:OWIN的理解和实践(三) –Middleware开发入门 上篇我们谈了Host和Server的建立,但Host和Server无法产出任何有实际意义的内容,真正的内容来自于加载于Server的Middleware,本篇我们就着重介绍下Middleware的开发入门. Middleware是什么 如果把HTTP交互理解为一次答题活动,那么Request是问题,Response就是答案,Server是课堂,Middleware就是参与者,注意我这里用的是参与而不是解答,因为我们允许有些Midd

VirtualBox Host-only理解与实践

1 概念理解 host-only顾名思义,这种技术提供的是主机和虚拟机之间的网络互访,而不是虚拟机访问internet的技术. 在某些特殊的网络调试环境中,要求将真实环境和虚拟环境隔离开(就是说不希望外网环境访问虚拟机,也不希望虚拟机访问外网环境),这时你就可采用host-only模式.在host-only模式中,所有的虚拟系统是可以相互通信的,但虚拟系统和真实的网络是被隔离开的. 提示:在host-only模式下,虚拟系统和宿主机器系统是可以相互通信的,相当于这两台机器通过双绞线互连. 个人认

对GCD的一些理解和实践

GCD GCD,全程Grand Central Dispatch,是苹果为了多核并行提出的解决方案.它是使用C语言实现,但是由于用了block来处理回调,所以使用起来十分方便.并且GCD会自动管理线程的生命周期,不需要我们去管理. 任务和队列 GCD中有两个重要的概念,任务和队列. 1.任务,就是我们想要处理的事情,任务可以分为同步执行和异步执行: 同步(sync):使用dispatch_sync(dispatch_queue_t queue, dispatch_block_t block) 创

对Google C++编程规范的理解和实践

1. #define保护 所有头文件都应该使用#define 防止头文件被多重包含(multiple  inclusion),命名格式为: <PROJECT>_<PATH>_<FILE>_H_ 为保证唯一性,头文件的命名应基于其所在项目源代码树的全路径.例如,项目foo 中的头文件 foo/src/bar/baz.h按如下方式保护: #ifndef FOO_BAR_BAZ_H_ #define FOO_BAR_BAZ_H_ ... #endif // FOO_BAR_B

对于CocoaPods的简单理解,实践安装使用过程和常见问题

(本文是自己通过其他文章进行的自我编辑和简单修改,请大家凑活看看) 一.什么是CocoaPods CocoaPods是iOS项目的依赖管理工具,该项目源码在Github上管理.开发iOS项目不可避免地要使用第三方开源库,CocoaPods的出现使得我们可以节省设置和第三方开源库的时间. 在使用CocoaPods之前,开发项目需要用到第三方开源库的时候,我们需要 1.把开源库的源代码复制到项目中 2.添加一些依赖框架和动态库 3.设置-ObjC,-fno-objc-arc等参数 4.管理他们的更新

对于src路径问题,深层理解的实践。且对于输出流write()两个方法的源码阅读。

根据昨天的总结,可深层理解图片中src的路径.所以今天实现了一个想法.就是路径写入的是Controller,然后自动去本地找. 其实就是将电脑的本地图片 显示出来.通过输出流的方式. 代码如下: @RequestMapping(value = "/img/{id}") public void img(@PathVariable(value = "id") String id,HttpServletResponse response) { File file = ne

Spring Cloud Hystrix理解与实践(一):搭建简单监控集群

前言 在分布式架构中,所谓的断路器模式是指当某个服务发生故障之后,通过断路器的故障监控,向调用方返回一个错误响应,这样就不会使得线程因调用故障服务被长时间占用不释放,避免故障的继续蔓延.Spring Cloud Hystrix实现了断路器,线程隔离等一系列服务保护功能,它是基于Netflix的开源框架Hystrix实现的. 目的不是介绍Hystrix的与原理.及其使用等(有时间也要记录啊),而是通过实战搭建一个简单的监控集群,使用Hystrix Dashboard仪表盘动态监控展示以此来加深对H

浏览器缓存机制深入理解与实践(一)

我们在web开发中常常会遇到这样的场景,有一些较大和常用的资源(例如图片.文档.js.css),在页面打开初始化的时候并不需要用到,而是在用户与页面互动操作触发了某些条件时才需要这些资源(例如我们打开微博可能并不是为了看热搜,但大多数时候我们会点进热搜查看热搜新闻). 那么问题来了,如果用户去点击查看热搜时,我们才去加载热搜所需要的相应的资源数据,就显得很被动了.因为在最常用的功能中,来耗费时间等待,这对用户来说其实并不是一个非常好的体验.所以,我们首先想到的是提前将这部分资源加载到浏览器缓存中