(注:标题与文章内容无关)
在WF的Activity中，Delay是一个比效简单的组件，几分种就可以掌握他的事件、属性
在实际的业务应用中，有一类结点叫做"默认许可(否决)"，这类应成非常多，由其是在电子政务、法务、商务应用中。比如：
"自收到通知之日起X日内不提起上诉...."
"自收到申请之次日起，5日内不做出答复视为同意"
"两年内不主张债，法律不再保护"
"在3个月的公告期内如无人提出异议....."
还有一类叫做"到时提醒"结点,比如：
"闹钟"
以上的两类业务结点可以使用Delay实现，设计时应注意如下几点:
Delay会触发引擎的idle事件，当引擎加载持久化服务后，会对该状态的实例持久化.我们还可以设置引擎是否把进入idle状态的实例移出引擎。具体代码细节我在其他文章中已有说明，这里就不细说了，将进入idle状态的实例持久化是很重要的，因为一个Delay可能会延时几天或者几个月，如不将其持久化，风险太大，这个问题大家都明白。这里就不多说了。
我想说另一个话题:将进入idle状态的实例有选择的移出引擎，再适时的装入引擎
在设计一个工作流的初期调试中，不考虑"将进入idle状态的实例有选择的移出引擎，再适时的装入引擎"，不会有任何问题，可当系统运行后大量的idle实例会严重耗费系统资源。所以设计时要考虑如下几点:
1.是将所有的Delay都移出引擎;还是只将待定的Delay移出引擎.
2.如果有选择性的移出,分界标准是什么。
3.引擎默认会自动刷入移出的Delay，对于长延时的Delay如何解决
4.如何保证长延时Delay可以准时的被刷入
5.如何实现精确延时
5.是否要使用双引擎，其中一个作为时间引擎独立处理Delay
然后我们还要考虑延时计算的算法:
1.有效日期的算法，比如"300个工作日内完成"，那么扣除法定假日的300个工作日如何计算
2.使用法定假日码表计算工作日时，如何解决临时节假日问题(比如出现1999年10.1那种国家庆典部分行政行为法定延期的情况)
3.如果出现法定延时，是直接修改Delay的延时属性，还是使用超时补偿，还是动态插入一个法定延时的Delay
4.使用什么样的时间轴，解决时区差,如中美之间的电子商务
5.使用什么样的时间轴，解决农历提酲，如库存系统提示农历八月十五的月饼进货流程
还有，连2008奥运会这样的大事都得在大街上立个倒记时的牌子,防止12亿中国人同时忘了，
我们至少也得为用户提供一套时间预警方安吧。
以上是对设计工作流该类结点的一些总结，在实际设计中，跟据不同的业务需求，还会有更多的演化。
总之，设计工作流，先了解、理解、精通所面对的工作，才能让"工作" 在系统中"流"起来
工作流所涉及的面很广,一个人不可能从代码、架构、需求上将所有工作流全部搞定,
这个博客建了半个月了,文章也了40几篇,就是抛砖引玉了，希望能与大家多进行一些交流,共同学习共同进步