Kogito人机规则-第1部分：进一步解决流口水

Kogito计划是我们承诺将我们的业务自动化套件引入云和更大的Kubernetes生态系统的承诺。但这对我们钟爱的规则引擎Drools意味着什么？在这篇文章中，我们介绍使用规则单元的模块化规则库：一个特点，一直是在Drools中7一段时间的实验 ，但是这将是其Kogito，它会发挥更大的作用。这是系列文章的第一篇，我们将向您概述此功能。

让流口水更进一步

Drools是我们最新的，高性能，功能丰富的开源规则引擎 。人们喜欢它，因为它是瑞士军刀 ，可以解决基于规则的人工智能可以解决的许多问题。但是随着计算机编程领域的发展，我们还需要考虑各种方法来带来更多Drools。您可能已经知道， Kogito是我们努力使Drools和jBPM真正成为云原生，并且非常适合无服务器部署：我们采用Quarkus框架和GraalVM的本机二进制编译，以实现超快速的启动时间和低内存。脚印; 但是我们不止于此。

我们希望带给Drools进一步发展的方式是双重的 ：一方面，我们希望通过提供更好的方法来定义规则库中具有更好模块概念的边界，从而使我们的编程模型更易于推理 。另一方面，模块化编程的概念至少可以追溯到1970年代和Parnas最初的开创性论文。不用说，如果我们的贡献到此为止，我们将不会带来任何新的变化。在过去的几年中，计算技术已经发展，缓慢但稳定地迎来了多核和分布式革命 。然而，到目前为止，许多通用编程语言并没有真正使编写并行或分布式程序变得简单。规则为基础的编程系统，我们必须提出一些不同的机会：一个规则引擎，是伟大的 单机时，但优秀的在云中。

模块化规则库。 如您所知，Drools提供了一种将规则集划分为知识库的便捷方法。这样的知识库可以组合在一起，产生更大的规则集。当实例化一个知识库（所谓的会话）时，规则被放到同一执行环境（ 生产内存 ）中，而值（事实）都被插入到同一工作内存中 。

这个模型非常简单和强大，但是从某种意义上说它也非常有限 。这非常简单，因为作为规则库的用户，您只需要担心数据：将值插入到工作内存中，引擎就发挥了不可思议的作用。它非常强大，因为作为规则作者，您可以依靠编写的规则来实现复杂的推理流程，而不必担心它们将如何触发以及何时触发。

同时，这种执行模型缺少所有原则，这些年来，我们一直在学习的是良好的编程实践。例如，没有适当的模块概念：不可能将一个规则与另一个规则完全隔离，也无法正确划分工作内存。随着规则库复杂性的增加，可能很难理解触发哪些规则以及为什么触发。从某种意义上说，就好像您在一个不存在适当的状态封装的奇怪世界中进行编程一样，好像没有发生多年的编程语言演进一样。

面向对象的编程。 多年来，面向对象程序设计一词已被重载，以表示许多不同的事物。它必须与继承， 状态封装 ， 代码重用和多态性有关 。所有这些术语经常引起混淆，但它们并不是真正相关的：您可以重用代码而无需继承，可以封装状态而无需对象，可以编写多态代码而无需类。最近，诸如Go和Rust之类的命令式编程语言没有附带适当的类，但是它们支持一种面向对象的形式。 C ++的父亲Bjarne Stroustrup甚至在2015年发表了精彩的演讲，展示了他的孩子如何在不继承的情况下支持面向对象。

艾伦·凯（Alan Kay）是他在施乐（Xerox）的Smalltalk生涯中的父亲，他在OOPSLA 1997的鼓舞人心的演讲中说：“我组成了“面向对象”，我可以告诉你我没有C ++ 。实际上，艾伦·凯（Alan Kay）率先提出的对象概念更类似于参与者和微服务的概念。在正确的面向对象程序设计中，对象通过与外部世界交换消息（通常称为方法）来封装其内部状态并公开其行为。

如今，参与者系统已经复兴，消息总线对于今天我们称为反应式编程的中心非常重要，微服务几乎是理所当然的。因此，我们想知道，Drools成为这种新编程环境的一流公民意味着什么？

Kogito，ergo Cloud

在下一篇文章中，我们将看到我们使用规则单元进行基于规则的模块化编程。规则单元将为普通知识库构成和执行的扩展模型提供替代方案。我们相信，规则单元将为更广泛的用例（包括并行和分布式体系结构）留出空间。请继续关注它们如何适应Kogito的故事，以及它们可能为我们的自动化平台的未来带来的令人兴奋的可能性。