我从某人那里听说他们正在使用业务流程自动化工具(如 Weblogic 集成)作为一种编程语言(听起来有点愚蠢)来使事情具有声明性。然后他们将所有逻辑放入一个流程中,每一个if
和while
.
但是,过程不是一个如何一步一步地实现目标的实体吗?
对我来说,它使一个过程完全必要。你怎么看?
我从某人那里听说他们正在使用业务流程自动化工具(如 Weblogic 集成)作为一种编程语言(听起来有点愚蠢)来使事情具有声明性。然后他们将所有逻辑放入一个流程中,每一个if
和while
.
但是,过程不是一个如何一步一步地实现目标的实体吗?
对我来说,它使一个过程完全必要。你怎么看?
编排语言实际上是具有条件、循环和其他传统命令式结构的命令式脚本语言,通常通过基于流程图的用户界面来表示。他们当然不会(根据我的经验)实现尾递归函数式编程、反向链接或任何其他在普遍接受的意义上可能被合理地描述为声明性的范式。
MS Workflow Foundation 被宣传为具有规则引擎,但这相当简单,并没有真正进行前向链接,除非以某种迂回的方式。ILOG 实际上为他们的规则引擎制作了一个适配器,专门用于将其放入 MS 工作流基础。
其他工作流工具具有更好的规则引擎和适当的前向链接系统,可以被视为声明性的。但是,一旦您使用循环和条件分支进入工作流本身,您就绝对处于命令式编程的领域。
然而,一些系统也为工作流实现了基于 petri-net 或状态变化的标记系统,这可能被合理地描述为声明性的,但它们仍然具有与底层系统交互的命令式模式。它们仍然会更新变量并具有副作用。
我见过一两个应用程序(例如用于数据分析的 TOAD)实际上使用 MS Workflow Foundation 作为脚本语言。因此,它允许您向应用程序添加一个脚本工具,该工具(至少出于营销目的)不需要使用编程技能。
在实践中,为编写、编辑和运行 SQL 查询而设计的工具配备了面向“非程序员”的脚本框架,这让人们想知道它的真正目标受众是什么。作为一种脚本语言,工作流建模工具相当笨拙,提供的抽象机会非常有限;在实践中,基于 .Net 的脚本语言(例如 IronPython 或 Boo),特别是与体面的模板机制相结合,将是对此类工具的非常强大的补充。
关于这种图形语言的一点是它们不能很好地适应复杂性。类似的问题也适用于 ETL 工具。我看到了一个使用 Crossworlds(现在称为 Websphere Integrator)(讽刺地)完成的配置应用程序(见下文)。在应用程序启动后的一个月内,很明显图形工作流语言无法随着应用程序的复杂性而扩展,并且基于用 Java 编写的自定义规则引擎和相当大的定制程序重新构建了它爪哇代码。
这种类型的问题在 EAI 和编排系统中并不少见,也是SOA在实践中难以实施的原因之一。您正在做的实际上是将业务逻辑推入一个非常笨拙的编程环境中,而该环境并未得到官方认可。这将在一个简单的情况下工作,但很难在一个复杂的系统上工作——这在 SOA 圈子中是一个有罪的秘密。
Coda: 配置应用程序是一个系统,它为电信服务合同(在本例中为移动电话网络)制定计划,并根据规则将配置信息推送到各种交换机、计费应用程序和其他应用程序。它们往往相当复杂。当您购买一个每月有这么多分钟和这么多文本的手机计划时,配置应用程序会将有关您的访问和计费规则的配置信息推送到系统的其余部分。
这绝对不是人们谈论声明式编程时通常所说的意思,即使在某种意义上可以称为声明式编程。