Hi to the product team.
The topic of multi-tenancy has been raised in connection with Corticon. For example, we have a situation where we will want to run one Corticon Server which hosts rules processing for multiple tenants. We want to ensure that each tenant’s rules are visible to and updatable by the tenant only. We would not want one tenant to see another’s rules, nor would we want the decision requests of one tenant to be evaluated by the rules of another, even though they might share common names for their decision services.
Is there a way to accomplish this today? Some sort of work-around, such as running multiple instances of Corticon on the same server?
What can we do to escalate the implementation of multi-tenancy as has been done in Roll Base and OpenEdge?
Looking forward to feedback from the group.
Patrick,
The Corticon server does not, out-of-the-box, support multi-tenancy.
If you deploy Corticon's axis.war it provides the Corticon server wrapped behind a SOAP and REST interface. These each provide a single "execute" entry point that is called to execute a decision service. The decision service to execute is specified as an attribute in the request. A client with access to the execute entry point via either SOAP or REST could call any decision service. This would be unsecure.
Inside Corticon's axis.war the SOAP and REST interfaces are just thin layers around the Corticon server. If you were to develop your own SOAP or REST wrapper you could apply your own security mechanisms and define your own interface to meet your needs. Wrapping the server in your own interface gives you lots of freedom but you also are responsible for ensuring its secure.
Assuming you solve the "who can call which decision service" problem you still have challenges. Where each decision service is running in the same server you would want to restrict the use of service call outs or extended operators. The custom code behind these would have access to the Corticon server and would not be secure. EDC usage would pose additional challenges.
A better option may be to deploy multiple instance of the Corticon server. If you provide unique SOAP/REST entry points for each tenant and provide the requisite security in your application server then you would be able to isolate the decision services to just authorized tenants. There would be more overhead in this approach. In addition each instance would need it's own work directory so they don't conflict.
A problem you could still have is decision services monopolizing the server. There would be no provision for restricting the CPU usage of a tenant.
There is no complete solution currently.
Jim