我们正在重写一个大型遗留系统,该系统会大量(错误地)使用工作流引擎。展望未来,我想考虑新应用程序的工作流引擎的替代方案。一个非常有趣的可能性是Space-based architecture +规则引擎。还有哪些其他范例?
我会提到这个应用程序根据国家/地区/等方式编排了许多不同的调整来编排复杂的文档发布工作流程,但是如果可能的话,我想让答案更加通用。
修改:我为此问题添加了赏金以获得更多反馈。我想听听实际实施工作流程替代方案的人的意见。如果没有产生任何结果,我会接受BPEL的答案,尽管我对技术本身完全不了解。
答案 0 :(得分:2)
基于BPEL的流程是一种选择。如果您设想利用未来的BPEL工具来完成工作,那么您将走这条路。否则,BPEL就是一种过于复杂的混乱(因为所有这些通用的“所有可以插入”的解决方案都是)。
简单的事情是要意识到工作流通常是关于队列而不是工作流。也就是说,它更多的是将某些东西放在某人的桌面上,而不是按照严格的模式指导工作流程。在那种情况下,某个东西包含一个队列,这是一个已定义的工作阶段,然后以灵活的方式链接到其他潜在的工作块。有一个通用的过程,但该过程有例外。规则引擎可以在队列之间移动事物作为一般过程(并根据需要启动外部过程),并且当定义的规则不切断时,用户可以选择将事物移动到“正确”队列中。
答案 1 :(得分:2)
这似乎是一个明显的反应,但没有其他人提出过它,所以这里有:您是否考虑过文档(或内容)管理软件?
答案 2 :(得分:2)
您可以严格地将其作为基于用户或文化或其他任何动态构建的有限状态机引擎。您需要将特定自动机作为长期运行事务的状态持久化。然后,当用户重新调用状态或采取另一个“动作”(基本上建模为状态转换)时,允许转换具有输出(Mealy机器)或新状态(Moore机器)。
答案 3 :(得分:1)
嗯,您已经提到了基于规则的处理。基于事件的处理模型有点类似,但在响应事件方面不太正式。总的来说,我不认为一个人必须完全遵守特定的模式。
(例如,基于事件的前端 - >基于规则的编排 - >特定(线性)工作流程处理。)
答案 4 :(得分:1)
如果你从30,000英尺看它,你有两个选择:
在这两种情况下,“规则”都可以在工作流程/编排,规则引擎或代码中定义。
我们已选择根据以下标准实施系统:
我使用MS技术,因此对于您描述的系统类型,我会在Sharepoint中实现它,它具有文档管理系统和用于文档管理的内置工作流程。入门级Sharepoint许可证Windows Sharepoint Services包含在操作系统中。
答案 5 :(得分:1)
从KISS的角度来看,工作流只不过是队列和规则引擎就是其他 - 我们有一个文档系统,我们有像处理一样的工作流程。我们考虑了websphere的工作流程以及来自weblogic的WLI,但是带有持久存储的JMS(MDB以及唤醒者)的简单工作对我们来说非常有效,没有任何问题。我认为你在这里采取了正确的方法 - 祝你好运!
答案 6 :(得分:0)
NetBpm(JBpm的.Net端口)
答案 7 :(得分:-1)
您可以考虑使用Apache Camel。 它是EIP和大多数工作流语言,如if,choice支持,但你必须为它编写代码。