py工作流分析

py工作流是国内比较好的工作流之一。大概看过它的一些文档，分析一下。
1、路由模型
 py支持的工作流模式其实并不多，只是支持1到7七种模式而已，其中比较重要的是模式6和模式7，即M选N分支和
 M选N聚合，看过它的实现，利用转移线条件来触发转移线，从而触发后续的节点。这样做比较简单，但是同时也存在很多问题，例如在路由非常复杂的情况下，例如多个分支节点的串联，以及并发路由存在多个节点时，这种做法实现起来就非常困难。另外，并发路由的工作流变量会存在相互冲突的情况，也包括业务数据的冲突。可以说py的路由模型还是很简单的，支持简单的业务可能没有问题，对于复杂的业务可能需要很多其他额外的办法。当然，很多国内的工作流甚至连模式6和模式7都支持不了，同时工作流的应用目前还具有很浓的“审批”的影子（貌似有人很讨厌审批这个说法），所以目前的路由模型应该满足需求了。
2、任意路由和回退
 没有看到任意路由和回退的复杂示例。关于任意路由，产品说明中说到可以在整个流程范围内任意自由路由，我觉得这个说法本来就是有问题的，并发路由的情况下，并发支线往主线上跳转，这种情况会有很多问题存在，其他并行的支线如何处理？或者说根本就没有考虑到这些复杂的情况？回退也是一样的道理，至于业务补偿的提出还是不错的，不过推给了用户自己设置回退动作。
3、关于WFMC和BPEL规范
 看看流程定义文件就知道了，它不支持任何规范。敢说国内工作流的流程定义就没有遵循规范的。
4、参与者的指定
 提供了组织机构、角色、个人这三种常见的参与者设置模式，还提供了流程启动者、活动执行者、从相关数据或从规则逻辑中获取参与者的模式。
5、工作的代理和代办
6、时间服务
 提供了四种时限。活动提醒、活动执行、流程提醒、流程执行。
7、业务开发
 感觉这是非常出彩的地方，在一个简单的示例中几乎不需要任何编码，比如一个简单的请假管理。看看它的流程定义文件，它几乎将整个业务表单都嵌入到流程定义里去了。这样做是否合适？我个人倾向于引擎与业务完全分开，通过反射或者某种映射将两者关联到一起。如果是用户自己开发已有的复杂业务，如何将工作流嵌入？至于studio也是非常出色的，具有开发调试的功能。调用接口非常的清晰。
总结一下： py工作流还是一个不错的工作流引擎，抛开它的宣传，感觉引擎的实现还是有些简单，或者说只是满足了目前的一些常见需求，至于所说的SOA和服务编排，我觉得目前还不现实。它的优势在于与其平台的完全融合，能够利用很多既有设施，可是这又何尝不是把双刃剑？另外，强大的市场宣传和良好的服务团队也是选择工作流时的重要考虑。