java - 通过 REST 调用 BRMS/Drools Logic 的良好设计

Question

我正在开发一个使用 .NET 和 Java 构建的应用程序。 Java 组件包含使用 Redhat BRMS 套件的完整规则库。 .NET 客户端(基于 UI 和桌面的应用程序)将咨询 Java 规则引擎并发送/接收 JSON 数据。已做出的决定是将规则引擎(使用 Drools 的 Redhat BRMS 6.0.0)公开为基于 REST 的 API。我想出了以下设计方法:

1. 在 Spring 框架和调用 BRMS 的服务类中编写一个 REST Controller 。
2. 使用 JBOSS 专有的 RESTSY 或 JAXRS 编写一个简单的 REST Controller 。
3. 编写一个 Camel 适配器并将 REST 调用包装在 Camel 后面，让 Camel 与 Drools 对话。
4. 将 REST 包装在基于 SOAP 的网络服务之后。

我想问一下哪一个是更好的设计方法，例如系统。

欢迎任何其他想法。

Answer 1

从 https://github.com/gratiartis/sctrcd-payment-validation-web 可以明显看出和 https://github.com/gratiartis/qzr我的一般偏好是在 Spring 应用程序中使用 REST API 公开我的 Drools 业务规则。

我在上面的列表中考虑的唯一选择是 4，其中 API 通过 SOAP Web 服务公开。尽管绝对不是包装 JSON REST 服务!设计良好的 Spring 应用程序可以轻松地通过 REST 和 SOAP API 公开功能。

在使用 .NET 客户端时，我通常通过 SOAP 进行公开。首先，.NET 工具非常支持基于您定义的 WSDL 生成代理。其次，WSDL 形成了您和客户端开发人员都必须遵守的明确定义的契约。签订严格的契约(Contract)对于防止争论非常有用。尽管如果您的界面很简单，它可能不会带来太大好处。

另一个关键原因是 WSDL 不会更改，除非您有意更改它。 REST JSON API 似乎可以快速开发，这要归功于 Jackson 为您生成的一切。但是，它可以公开您的内部对象模型(和依赖项!)，这意味着除非您小心，否则对内部模型看似微不足道的更改可能会使私有(private)数据可见并可能破坏客户端。

总而言之，如果您可以保持 API 相当简单并与 .NET 开发人员保持良好关系(也许您就是其中之一)，那么我建议使用 Spring REST API。如果可以帮助您入门，请随意从 github 存储库中窃取代码!

顺便说一句 - 如果您考虑使用 Camel，值得注意的是有一个 Drools-Camel 组件可以为您完成很多工作。