WF与Windows操作系统的对比

——通过AEC解读WF的核心原理(十一)(题外篇)

有的时侯，在开发Activity的时候，所用的方案思路，所面临的问题，所出现的错误，总有一种似曾相似的感觉，比如C时，忘了释放指针，我总会打自已一下，开发Activity时，忘了Close,我会打自已一下......

觉得WF的结构与操作系统有很多相似之处，下面我就对比一下:

对比项

操作系统

宿主，

计算机

宿主：

WorkflowRuntime,的寄生环境

计算机：

操作系统的的寄生环境

WorkflowRuntime,

操作系统

WorkflowRuntime：

工作流的运行环境

操作系统：

应用程序的运行环境

工作流,

应用程序

工作流:

可在WorkflowRuntime中运行的，用于完成各种业务功能的独立代码单元

应用程序:

可在操作系统中运行的，用于完成各种业务功能的独立代码单元

实例,

进程

实例:

工作流在WorkflowRuntime中的一种激活状态

进程：

应用程序在操作系统中的一种激活状态

WF加载服务,

驱动程序

WF加载服务：

由WorkflowRuntime加载，为工作流的实例提供某种功能或接口

驱动程序：

由操作系统加载，为应用程序的进程提供某种功能或接口

Activity(DLL)格式工作流,

Win32格式程序

Activity(DLL)格式工作流:

WF工作流的基本格式,WF的"本地代码"

Win32格式程序:

Win操作系统的基本格式,本地代码"

xoml格式工作流,

NET格式程序

xoml格式工作流:

一种用字符串方式描述执行逻辑的文件，可由DefaultWorkflowLoaderService将其解释成

WF的"本地代码"在WorkflowRuntime中运行

NET格式程序:

一种用字符串方式描述执行逻辑的文件，可由NET Framework将其解释成"本地代码"在操作系统中运行

DefaultWorkflowLoaderService,

NET Framework

DefaultWorkflowLoaderService:

xoml的解释器，WF默认加载

NET Framework:

NET格式程序的解释器，操作系统默认安装

其它格式工作流,

Java格式程序

其它格式工作流:

WF可以加载其它xml格式的的工作流描述件，但需基于WorkflowLoaderService实现该格式的解释器，并加载到WorkflowRuntime中

Java格式程序:

可以在Win操作系统运行，但需要安装Java 虚拟机

自定义WorkflowLoaderService,

Java 虚拟机

自定义WorkflowLoaderService:

实现自定义工作流描述件格式的解释器

Java 虚拟机：

一种将Java格式程序解释并在操作系统中运行的中间环境

并行,

线程

并行:

WF的ParallelActivity并不是启用线程实现分支的并行，而是在各分支上交错执行，以实现并行效果

线程:

Win操作系统的多线程并不依赖多核CPU,它可以用一种交错方式执行，以实现多线程并行效果

WorkflowQueuingService,

系统消息

WorkflowQueuingService：

WF为实现交互而提供的一种通信响应接口，AEC , WorkflowRuntimeService , IServiceProvider

系统消息:

操作系统为实现交互而提供的一种通信响应接口,Hook,SetWindowsHookEx,CallNextHookEx

持久化,

休眠(不是待机)

持久化:

WF可以将WorkflowRuntime中的实例保存起来，当关闭WorkflowRuntime后，再启动WorkflowRuntime可以继续运行实例

休眠：

WIN操作系统可以将当前运行的系统保存到磁盘，后断电，当重新启动后可以继续使用休眠前系统中正在运行的进程

持久化,

虚拟内存

持久化：

WF可以将WorkflowRuntime中的不运行的实例保存到磁盘，以解省内存。当实例需要继续运行时再从磁盘加载到内存

虚拟内存:

WIN操作系统不运行的进程保存到磁盘，以解省内存。当进程需要继续运行时再从磁盘加载到内存

WF,

操作系统

WF:

操作系统中运行的一个程序

操作系统:

也许有一天，可以用一个可以像WF这样的可视化开发环境设计操作系统

说明:

如果从求同的角度，你会发现铅笔与太阳是一样的，如果从求异的角度，两个水分子的差别用137亿年也描述不完，本文不是一篇技术文章，有些比效也并不准确，只是对技术的一种调侃