Good Design for calling BRMS/Drools Logic over REST

Question

I am working on an application which is built in .NET and Java. The Java component contains the complete Rule base using Redhat BRMS suite. The .NET client (UI and desktop based applications) will be consulting the Java Rule engine and sending/receiving the JSON data. The decision which has been taken is to expose the Rules engine (Redhat BRMS 6.0.0 using Drools) as a REST based API. I have come-up with the following design approaches:

1. Write a REST controller in Spring framework and service classes for calling BRMS.
2. Write a simple REST controller using JBOSS proprietary RESTSY or JAXRS.
3. Write a Camel adapter and wrap the REST calls behind the Camel and let the Camel talk to Drools.
4. Wrap REST behind SOAP based webservices.

I want to ask which one would be the better approach for designing such as System.

Any other thoughts are welcome.

Answer 1

As might be obvious from https://github.com/gratiartis/sctrcd-payment-validation-web and https://github.com/gratiartis/qzr my general preference is for exposing my Drools business rules using REST APIs in a Spring application.

The only alternative I consider in the above list is 4, where the API is exposed through a SOAP web service. Albeit definitely not wrapping a JSON REST service! A well-designed Spring application can expose functionality through both REST and SOAP APIs with very little effort.

I have usually exposed via SOAP when working with .NET clients. Firstly, the .NET tooling has excellent support for generating proxies based on WSDL that you have defined. Secondly, the WSDL forms a well-defined contract which both you and the client developers must obey. Having a strict contract can be very useful in preventing arguments. Although if your interface is simple, it may not be so much of a benefit.

The other key reason is that the WSDL does not change unless you change it deliberately. A REST JSON API may seem quick to develop, thanks to Jackson generating everything for you. However, it can expose your internal object model (and dependencies!), meaning that unless you are careful, what seems like a trivial change to an internal model can make private data visible and can break clients.

All that said, if you can keep the API reasonably simple and have a good relationship with the .NET devs (perhaps you're one of them), then going with the Spring REST API would be my recommendation. Feel free to steal code from the github repos if it can help you get started!

btw - If you were to consider Camel, it's worth noting that there is a Drools-Camel component which does quite a bit of the work for you.

Answer 2

In my view,

I would go with the option 1. This is the simplest and easiest approach.

Option 2 may be second choice.

Option 3 - Looks like if there are some routing rules you could choose. Again its could make it complex.

And definitely not option 4 to make it complicated with SOAP.