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