第1部分 入门
第1章 关于工作流
这是一本谈Windows Workflow Foundation的书，书中的主角当然就是Windows Workflow Foundation（简称WF）。作为.NET Framework 3.0中主要的技术成员之一，WF可以说是微软软件开发技术史中，最重要、也是被误解最多的技术之一。要充分掌握WF的应用时机很容易，也很困难，最主要的原因还是在于大家对工作流这件事的期望很高。所以，在开始讨论wF之前，我们先来谈一些历史。
1.1 Workflow Foundation概述
1.1.1 从BizTalk Orchestration开始
微软从很早以前就开始有工作流相关的技术，最早应该追溯到Exchange。当时Exchange最大的敌人是Lotus Notes，Exchange的出现，让微软在MS—Mail面对Notes的颓势中扳回一城，让微软的电子邮件产品也能够以客户端，服务器架构面对敌人，而不是通过文件共享的方式来提供信息服务。不过，在Notes以群组软件的方式现身，并且涉足工作流领域后，Exchange面对的，就是一个顽强的敌人。要改善这个状况，最直接的方式就是提供界面设计功能，并且加上工作流的服务。于是微软在Exchange中提出了路由对象的技术，企图结合既有的电子表单开发技术，为企业提供一个建立工作流解决方案的平台。
不过，这项技术的效果并不好，它存在太多的障碍而形成使用的门槛。其中最大的问题在于当时的微软有太多开发技术，却欠缺一致的底层操作平台，使得很多技术看起来像大杂烩一样。就以Exchange要提供的工作流技术为例，它的流程定义是通过COM来实现的，却没有图形化的设计工具，所以要建立流程就必须靠程序代码；但若是通过Exchange的窗体技术来建立电子表单，拉窗体的方式将类似Visual Basic的控件拖拽方式，但是事件处理程序要运用脚本，、而且缺乏调试工具，这就痛苦了。又或者可以通过HTML页面设计，那需要使用R0却又必花费一番功夫。简单来说，开发一个工作流解决方案必须面对好几个设计工具，而没有图形化工具设计流程，就注定了它的失败。
后续几个和工作流有关的技术都不令人满意，SQL Server也开发了一项工作流技术，开发工具是Access，并提供了一个流程设计接口，但很简陋，简陋到它只能定义程序流程，难以定义更高级的业务流程。之后的Site Server、Commerce Server、BizTalk Server都陆续推出一些与工作流相关的技术，彼此间的方式虽各有差异，但都是要解决工作流的问题。
展开
