Choice of architecture for exposing CLIPS expert system as web application

user_4105331 0
Viewed 394

I am relative new to developing web applications.

I would like your comments and suggestions of improvement for the following architectural considerations.

I have developed an expert system ES using CLIPS. Now I am planning to provide this to variety of users from our company as a web application. Before I start with going into greater details I am currently thinking about which technologies should be involved.

The goal is that the user of the web app is facing a chat-like animation which guides him to the final result while he or she provides more and more input to the ES.

After conducting some research on my own I came up with the following idea

In the backend I use PyCLIPS as an Interface between Python and CLIPS

Then I use DJANGO for integrating my python code into the web page dynamically altering the chat between user and ES.

There is one thing which is particularly still troubling me a lot: How shall I manage many concurrent users? Shall I use one ES with every user having an individual set of facts or shall every user have his or her own instance of the ES?

Do you have any other high level approaches for this problem which could be superior to this one?

I am looking forward to your experience and input regarding this matter.

Best

clips python-multithreading django web-applications python
2 Answers

I'd suggest running the expert system in a stateless mode. Each time the user makes changes, you submit all data from the web page to the expert system and then retrieve the results to display on the web page. Doing it that way scales better if you have multiple users and makes it easier to implement undo logic if the user wants to change a response. There's an example showing how to do this with a CGI application at http://www.clipsrules.net/?q=Downloads/CLIPSCGI.

user_2326420

It is usually a good idea to split your Expert System into separate "shards".

It keeps the rule base simpler (as you don't need to distinguish to which user a fact is referring to) and allows you to scale horizontally when more users will be added.

If running one ES per user sounds overkill, you can decrease the granularity by sharding based on, for example, the first letter of the user surname or Id.

When designing similar solutions I tend to de-couple the frontend application with the ES by using a queueing system. This allows you to modify the cluster layout without the need to change the public APIs.

| Flask | ----> | RabbitMQ | ----> | ES Worker |

In case you want to change your sharding strategy, you can simply re-configure the broker queues layout without affecting the client/end-user.

user_17944970
Related