J
James Arsenault
Guest
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
Continue reading...
Continue reading...