5

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

ocelord
  • 81
  • 1
  • 2

2 Answers2

2

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.

Gary Riley
  • 10,130
  • 2
  • 19
  • 34
  • CGI has too many shortcomings (and there are many better alternatives out there in 2021) for this to still be a viable solution. Does CLIPS have functionality that allows it to persist/load current STATE (facts, agenda, fired rules etc.)? I am aware of the `bload` and `bsave` but I don't know if they are sufficient in this case of restoring state. Your feedback appreciated. – Homunculus Reticulli Nov 25 '21 at 13:50
  • Running in a stateless mode is what I'm suggesting independently of what's used to display the GUI. All of the CLIPS example applications (C#, Java, iOS, CGI) run in this manner. If you want to persist the current state beyond the lifetime of the GUI, you'd need to use something like save-facts/bsave-facts to save the state or something similar. For example, the iOS examples save the state in the app preferences when the app terminates. – Gary Riley Nov 25 '21 at 17:51
  • Can a "session" STATE be maintained by persisting **ONLY** facts (via `bsave-facts` and `bload-facts`)? I am trying to do something similar - to have CLIPS run as a service (using an architecture similar to what @noxdafox suggested - would saving/retrieving facts allow me to run stateless CLIPS (assuming all the workers are running from the same set of rules - i.e. rulebase)? – Homunculus Reticulli Nov 25 '21 at 20:00
  • Yes, if your rules are just matching facts, you can maintain the session state by just saving facts. – Gary Riley Nov 26 '21 at 20:30
  • Could you please clarify the statement _"if your rules are just matching facts"_ - I thought the only way in which the inference engine worked was by matching facts (as per given rules)? What am I missing? Thanks – Homunculus Reticulli Nov 26 '21 at 21:29
  • CLIPS also has an object-oriented programming language. Rules can also match instances. – Gary Riley Nov 27 '21 at 00:16
  • Hopefully, this explains the architecture I have in mind a bit better: assume **A** is a remote client, **B** is an endpoint; A calls B ( A <->B). Further assume that B communicates with **C** (which represents either a running CLIPS executable, or an application that embeds CLIPS). B communicates with C through IPC, Shared Memory or some other mechanism. What is not clear to me, is how CLIPS can establish a bi-directional communication with B, so that (as far as CLIPS is concerned - B is a human typing at it's local console)? – Homunculus Reticulli Nov 27 '21 at 21:17
  • All of the examples for CLIPSJNI and CLIPSNET run the GUI on a separate thread from CLIPS, but the router demo example is probably the most relevant to your case. It uses the CLIPS I/O router system to establish bi-directional communication between CLIPS and the GUI to process I/O requests. – Gary Riley Nov 27 '21 at 23:00
  • Do you have a link to the CLIPS router demo? I can't find the router demo on CLIPS sourceforge page, and a Google search doesn't come up with any useful results either. Thanks – Homunculus Reticulli Nov 28 '21 at 11:50
  • Download either clips_jni_640 or clips_windows_projects_640 from https://sourceforge.net/projects/clipsrules/files/CLIPS/6.40/ – Gary Riley Nov 28 '21 at 17:15
1

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.

noxdafox
  • 14,439
  • 4
  • 33
  • 45