调用BRMS/Drools逻辑优于REST的良好设计

Question

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

1. 在Spring框架和服务类中编写一个REST控制器，用于调用BRMS
2. 使用JBOSS专有的RESTSY或JAXRS编写一个简单的REST控制器
3. 编写一个Camel适配器，将其余调用封装在Camel后面，让Camel与Drools对话
4. 将REST封装在基于SOAP的webservices后面

我想问一下，哪一种方法是设计此类系统的更好方法。

欢迎任何其他想法。

Answer 1

在我看来，

我会选择选项1。这是最简单的方法。

选项2可能是第二选择。

选项3-看起来好像有一些路由规则可以选择。同样，它可能会使它变得复杂。

而且绝对不是让SOAP变得复杂的选项4。

Answer 2

从中可以明显看出https://github.com/gratiartis/sctrcd-payment-validation-web和https://github.com/gratiartis/qzr我通常倾向于在Spring应用程序中使用RESTAPI公开Drools业务规则。

我在上面列表中考虑的唯一替代方案是4，其中API通过SOAP Web服务公开。尽管绝对没有包装JSON REST服务！设计良好的Spring应用程序可以通过REST和SOAP API公开功能，只需很少的努力。

我通常在工作时通过肥皂接触。NET客户端。首先是。NET工具非常支持基于您定义的WSDL生成代理。其次，WSDL形成了一个定义良好的契约，您和客户机开发人员都必须遵守该契约。有一个严格的合同对于防止争论非常有用。虽然如果您的界面很简单，但它可能不会带来太多好处。

另一个关键原因是WSDL不会更改，除非您故意更改它。由于Jackson为您生成了所有内容，REST JSON API似乎开发得很快。但是，它可以公开您的内部对象模型（和依赖项！），这意味着除非您小心，否则对内部模型看似微不足道的更改可能会使私有数据可见并可能破坏客户端。

综上所述，如果您能够使API保持合理的简单并与保持良好的关系。NET开发人员（也许您是其中之一），那么我建议使用Spring REST API。如果github repos可以帮助您入门，那么您可以随意从中窃取代码！

顺便说一句——如果你要考虑骆驼，值得注意的是有一个Drools-Camel组件可以为你做很多工作。