《WF编程》系列之47 第八章 工作流中的通信
2010-10-01 08:20:45 来源:WEB开发网核心提示: 工作流将会调用外部方法RequestVote,并把用户名作为参数传递,《WF编程》系列之47 第八章 工作流中的通信(3),服务有责任通知用户并等待收集用户的投票,服务还能将投票结果打包到一个事件参数对象中并触发VoteCompleted事件,技术组长的投票可能结束右边的分支,也就是我们为处理
工作流将会调用外部方法RequestVote,并把用户名作为参数传递。服务有责任通知用户并等待收集用户的投票。服务还能将投票结果打包到一个事件参数对象中并触发VoteCompleted事件。工作流将会接受这个事件,截取该事件的参数,并决定下一步要做什么。
现在想象一个工作流,就像下面截图中的那样:
当我们设计我们的服务接口时,我们假设工作流只会寻找到一个单独的投票。上面截图中的工作流在平行地寻找两个投票。该工作流将调用服务来请求小组技术组长的投票。该工作流还将调用服务来请求来自小组分析师的投票。然后在这个平行的活动完成之前,它会等待这些事件的到达。
注意:ParallelActivity活动,我们在第4章介绍过,并没有提供真正的平行处理。运行时只允许在一个工作流实例中每次执行一个线程。这里的平行活动将使用一个线程按照不确定的顺序执行这两个分支,直到它们阻塞或等待一个事件。既然这与投票小组中的一个成员要在很短的时间内作出投票响应是不同的,这两种平行活动的分支将会到达它们被阻塞的地方或等待它们各自事件的到达。
设想一下,小组的技术组长是第一个响应投票的。服务将会触发一个事件,工作流运行时将会截取这个事件。然后运行时将找到我们的工作流实例并发送这个事件。问题是——运行时将会把技术组长的投票发送到哪个分支的HandleExternalEvent活动呢,是左边的那个分支,还是右边的呢?我们不能肯定,技术组长的投票可能结束右边的分支,也就是我们为处理分析师的投票而设计的分支。这种场景代表了我们必须为运行时提供更多信息才能解决的问题。
- ››WF 4.0 beta1中的跟踪机制
- ››WF 4.0的建模风格:顺序和Flowchart
- ››WF4.0 Beta1之旅(5):规则引擎的变化
- ››WF 4.0 beta1活动概览(1):Procedural
- ››WF4.0 Beta1之旅(4):Bookmark的使用
- ››WF4.0 Beta1之旅:基本介绍
- ››WF4.0 Beta1之旅(2):异常处理
- ››WF4.0 Beta1之旅(3):全新的FlowChart
- ››WF 应用场景指南: SharePoint 与工作流(上)
- ››WF 应用场景指南: 展现流(Presentation Flow)
- ››WF单元测试系列1:测试基本的Activity
- ››WF单元测试系列2:简单测试Activity的行为
更多精彩
赞助商链接