很多人了解计算机程序设计是从学习流程图开始的，那些菱形矩形的简单图表往往能让流程逻辑一目了然。但流程图不是可以运行的软件，充其量只是一种文档，所以入门后大家往往将流程图抛诸脑后直接分析设计上手写代码。但流程图就真的只能作为文档吗？在很多方面代码比不上流程图：
1.一个程序员写的程序另一个人需要花很长时间看懂其中的逻辑，不像流程图一目了然
2.在运行时看不到代码的运行状况，不知道运行到了哪个阶段，这对大型项目管理带来障碍。
3.代码总是被封装在对象或过程里，对象（过程）之间需要额外的逻辑才能共享状态。
尽管一直不是软件开发的主流，但将流程图用在运行时总是一个不错的想法，尤其在文档生命周期管理、内部应用程序逻辑流转、BPM、Pageflow等场景下优势尤为明显：流程图在设计时高度灵活简便、运行时高度可见、管理更加方便。根据软件界水涨船高者生存的规则，以后很多公司为了提高自己的效率会不断接受引入工作流引擎到自己的产品中以避免重复发明劣质的轮子，面临的首要任务就是挑选合适的工作流引擎。那什么是理想中的工作流引擎呢？有人总结过工作流应该具备的一些支持模式，参见Workflow Pattern
http://en.wikipedia.org/wiki/Workflow_patterns
http://www.workflowpatterns.com/
这些都是很有益的总结，但由于有些厂商商业利益夹杂其中，所以硬扯了一些Process Model的东西。也有很多人和我当年一样，参照openwfc,bpel4ws或者其他一些需要实现的功能点写过自己单位用的工作流引擎并冠以自主知识产权之名，但实际上离真正的工作流还有一段距离。简而言之，一个相对完整的工作流平台必须具备的功能如下：
1.能够完成流程跳转。
2.宿主进程、宿主、运行时、工作流引擎等各层解耦完全
3.宿主进程多样化，至少要可以栖身与主流应用服务器上，避免使用者在非必要情况下自写应用服务器。
4.宿主层包含持久化、定时器、跟踪、事务支持等运行时服务。
5.运行时层工作流执行必须的编排器、规则引擎、跟踪基础框架与工作流生命周期管理必须的状态管理、激活、冬眠等解耦。
6.工作流引擎支持包含常用的时序、状态等模型
一个理想的工作流引擎除此之外还需要具备的功能如下：
1.宿主层支持与外界交互、多线程多进程支持等运行时服务，支持自定义运行时服务以便扩展。
2.工作流引擎支持的时序、状态等模型良好封装便于调用；引擎支持基于策略/规则的模型，支持自定义活动，为基于其上开发行业组件包的合作伙伴留出一条活路。
3.API良好组织调用简单，最好支持多语言多脚本。不要有稀奇古怪的流程定义语言，最好是业界已有的或者大家能很快接受的。
4.在设计时和运行时都有很多的辅助工具与注入代码的地方。
5.在设计时与运行时都有人性化的开发、调试、测试模板视图与设计器。
6.对常见中间格式如Plain Text,XML,Office Doc等有良好支持；对常见数据库、常见工业交换标准有所支持或有扩展支持的接口。
除此之外，还有好多功能其实不属于工作流重点关心的，但由于技术决策者需要所以理想的工作流引擎也必须考虑的：
1.边界清晰、服务自治、共享schema与策略而不是类、基于策略的服务兼容。明眼人可能一看就要拍桌子了，这不是WCF等分布式应用服务的设计原则吗，怎么扣到工作流头上来了？原因很简单，因为便于发布成服务的工作流才是可塑性最强的工作流，所以工作流在屋檐下，不得不低头，这也是微软为什么Silver(在.NET3.5中将WF发布成WCF)的原因。
2.支持长事务，支持人-人、人-系统、系统-人、系统-系统等四种方式的流程协作，支持全生命周期的动态透明管理，模型高度可扩展。
3.可在不同工作流进程/线程间方便地转移操作状态和数据，方便地进行补偿冲帐等操作。
基于以上考虑，大家可以看到微软的Windows Workflow Foundation已经完全可用了，当然还不是最理想的。有一个需要注意的是，笔者估计以后微软的工作流引擎会遇到一个发展怪圈，目前的WF虽然成熟程度已经比大多数国内公司做的自己的工作流引擎好多了，但还是抽象层级不高，虽然现在有Enterprise library在做的Pageflow，上文提到的Sliver等修修补补的工作，仍然难以挑起一统天下的重任。更大的原因是再往上做可能会碰到BizTalk Server或BizTalk Service的地盘（再次澄清一下后二者都不是工作流引擎）。只能寄希望于在Oslo中的表现了。
总体来说，基于流程开发将在近年对软件开发产生深远影响。大家可以现在开始按照以上标准选择自己心仪的工作流并应用到日常工作中。
重要申明：以上纯属个人观点，不代表任何公司意见，转载务请注明出处。
本文部分借鉴Paul Andrew，James Conard的见解，在此致以感谢!
|
