调用BRMS/Drools逻辑而非REST的良好设计

Question

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

1. 在Spring框架和服务类中编写一个REST控制器来调用BRMS。
2. 使用JBOSS专有的RESTSY或JAXRS编写一个简单的REST控制器。
3. 写一个“骆驼适配器”，然后把剩下的调用写在“骆驼”后面，让骆驼与口水交谈。
4. 将REST封装在基于SOAP的Wrap服务后面。

我想问一下，哪一种方法更适合于系统的设计。

任何其他想法都是受欢迎的。

Answer 1

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

我在上述列表中考虑的唯一选择是4，其中API是通过SOAP服务公开的。尽管绝对不是包装-- JSON服务！一个设计良好的Spring应用程序可以通过REST和SOAP公开功能，只需花费很少的精力。

在使用.NET客户端时，我通常是通过SOAP公开的。首先，.NET工具对基于您定义的WSDL生成代理提供了出色的支持。其次，WSDL形成了一个定义良好的契约，您和客户端开发人员都必须遵守该契约。有一份严格的合同对于防止争论是非常有用的。尽管您的界面很简单，但它可能没有那么大的好处。

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

尽管如此，如果您能够保持API相当简单，并与.NET开发人员保持良好的关系(也许您就是其中之一)，那么我建议您使用Spring。如果github repos可以帮助您入门，请随时从github repos中窃取代码！

顺便说一句，如果你考虑骆驼，值得注意的是，有一个口水-骆驼成分，它做了相当多的工作为你。

Answer 2

在我看来，

我同意备选方案1，这是最简单、最简单的方法。

备选案文2可以是第二选择。

选项3-看起来，如果有一些路由规则，你可以选择。再一次，它可能会使事情变得复杂。

当然也不是让SOAP变得复杂的选项4。