Talk:ServerBlueprints

Do we need/want Grails for the simulation server?
As of 2010-09-21, the demo server is implemented as a Groovy-on-Grails application. Is this the right platform? Here is why it might not be: Grampajohn 20:05, September 21, 2010 (UTC)
 * Grails is designed and optimized as a web-application platform. That means it is designed to support a large number of browser-based clients, primarily using stateless services and maintaining client state in a database. When a client connects, its state is temporarily restored from the database, a single request is processed, and the client goes away. This is known as a "reactive" architecture, in which the server primarily reacts to client requests.
 * The TAC Energy server, in contrast, is a highly-stateful simulator, connected to a small number of continuously-active broker clients.
 * The interaction model between server and broker is primarily proactive, not reactive, from the standpoint of the server. Ultimately we may have a mixed-initiative interaction model, but definitely not a reactive model.
 * It is not clear at all how the database-centric view of Grails brings much value to the server.

Suggestion for server refactoring
If Grails is not the right foundation for the simulation portion of the server, it is certainly appropriate for the server's web presence. That could include the following functions: So one way to think of the server would be to have a web front-end, built as a Grails app, managing potentially multiple instances of a (headless) simulation server, which in turn communicate with both the web front-end and its broker clients through Apache ActiveMQ.
 * User/competitor registration
 * Access to server log data from past simulation runs
 * Starting and stopping simulation runs
 * Competition scheduling
 * Generation and display of competition results
 * Viewing of current simulation runs

Grampajohn 00:21, September 22, 2010 (UTC)