流程设计真的是声明性编程吗？

Question

我听说有人使用业务流程自动化工具(如Weblogic Integration)作为编程语言(听起来有点愚蠢)来使事情具有声明性。然后他们把所有的逻辑放在一个流程中，每一个单独的if和while。

但是，不是一个如何一步一步实现目标的过程吗？

对我来说，它使一个过程变得完全势在必行。你认为如何？

Answer 1

这绝对不是人们在谈论declarative programming时通常所指的，即使它在某种意义上可以被称为声明性。

Answer 2

编排语言实际上是带有条件、循环和其他传统命令式构造的imperative scripting languages，通常通过基于流程图的用户界面来表示。他们当然没有(以我的经验)实现尾递归函数式编程、后向链接或任何其他可能被合理地描述为一般接受意义上的声明性的范例。

MS Workflow Foundation被宣传为有一个规则引擎，但这是相当简单的，除了以某种间接的方式外，并不真正做正向链接。ILOG实际上为他们的规则引擎做了一个适配器，专门把它放到MS workflow foundation中。

其他工作流工具有更好的规则引擎和适当的正向链接系统，可以看作是声明性的。然而，一旦你使用循环和条件分支进入工作流本身，你就肯定是在命令式编程的领域。

然而，一些系统还为工作流实现了基于petri网或状态更改的标记系统，这可以合理地描述为声明性的，但它们仍然具有与底层系统交互的命令性模式。它们仍然会更新变量，并且会有副作用。

我见过一两个应用程序(例如TOAD for data anlaysis)实际上使用MS Workflow Foundation作为脚本语言。因此，它允许您向应用程序添加不需要编程技能即可使用的脚本工具(至少出于营销目的)。

在实践中，一个为编写、编辑和运行SQL查询而设计的工具配备了一个面向“非程序员”的脚本框架，这让人不禁想知道它真正的目标受众是什么。作为一种脚本语言，工作流建模工具相当笨拙，提供的抽象机会非常有限；在实践中，基于.Net的脚本语言，如IronPython或Boo，特别是与良好的模板机制结合使用时，将是此类工具的一个非常强大的补充。

关于这类图形语言的一点是，它们不能很好地扩展复杂性。类似的问题也适用于ETL工具。我见过一个使用Crossworlds (现在称为Websphere Integrator) (讽刺地)完成的配置应用程序(见下文)。在应用程序启动的一个月内，很明显图形化工作流语言不会随着应用程序的复杂性而扩展，它被重新构建，基于用Java编写的自定义规则引擎和相当大的定制java代码。

这种类型的问题在企业应用集成和编排系统中并不少见，也是SOA难以在实践中实现的原因之一。您所做的实际上是将业务逻辑推到一个非常笨拙的编程环境中，而这种编程环境并没有得到官方的承认。这在简单的情况下可以工作，但很难在复杂的系统上工作-这在SOA圈子里是一种罪过的秘密。

Coda:供应应用程序是一个系统，它为电信服务合同(在本例中为移动电话网络)制定计划，并根据规则将配置信息推送到各种交换机、计费应用程序和其他应用程序。它们往往相当复杂。当你购买一个每月有这么多分钟和这么多文本的移动电话套餐时，配置应用程序会将有关您的访问和计费规则的配置信息推送到系统的其余部分。