I have created a simulation engine in Java. Depending on the parameters it can take quite long to run.
I want now to be able to expose it through a web App and allow the users to interact with the runtime engine modifying some conditions on "real-time". How can I make it available to my users so that they can interact with the simulation engine in runtime? Basically the process should be similar to:
User access my application and configures his simulation parameters
User is able to remotely modify/call some methods on specific objects during the simulation.
My idea was to expose a set of web services that will be used by users trough my Web App interface. However, I still have no idea how to connect this WSs to my "runtime". One of my ideas was to use directly DB to communicate ... but I guess there are better ways to do it (with probably better performance). If I should go to this path, I suppose I should use a DB with higher performance on inserts/reads (MongoDB?)
After some research I got to know about 2 approaches that I feel could be useful for my use case, but I don't know much about them. Those are:
Creating a thread and run it in the Servlet Context Listener Executor Service of a Tomcat Server
But still have no clear vision about implications of each one or even if there's any other better alternative...
If your service should be accessible through a web application, I strongly recommend writing a REST service. There are plenty of frameworks out there that will allow you to run REST services in a servlet container, such as Spring and Jersey.
The benefit over using RMI is that with REST you can easily communicate with your service from a client that's written in any language, so you can even create an HTML page that interacts with your service.
I once had a system which on worst-case days could take 18 hours to do a run.
You don't want to embed something like this in a webapp server, It holds the server hostage. If, for any reason, you need to restart the webapp server when a long-running process is in operation, that means you have only 2 choices: 1) kill the long-running process or 2) delay restarting the webapp server until the long-running process ends.
At the time I set up my long-running process, options were probably more limited, so what I did was construct a standalone RMI server to hold it. The webapp did RMI calls to monitor and control the process. There was no need of a web services interface, since normally the only way that the processor would be communicated with was via the GUI in the webapp. Had I needed an external control service, I could also simply make RMI calls directly.
These days I'd probably host the process in an application container such as the Apache felix/karaf/servicemix stack. These containers can not only hold offline apps, they can provide control/monitor/data interfaces using mechanisms like JMS or even act as web services hosts themselves. Plus I could implement the process as an OSGi bundle if I wanted.
Blitzlügen - Lies or information broadcast, but when called out the broadcaster does little or nothing is done to correct them, thus allowing those who wish to believe to accept them as truth.
Lügensturm - A barrage of Blitzlügen fired in such quick succession that it is essentially impossible to correct them all.
If you have a bad day in October, have a slice of banana cream pie. And this tiny ad: