When using a non-MVC service-oriented/Interactor pattern approach to decoupled system architecture, how is session state implemented?
I've been thinking of building the frontend of an application using MVC (PHP/Ruby etc.), and send messages to a command-line backend which is the actual application. Since I want the offline application to be completely in control of functionality I would imagine using an offline session management system to work best, which at login issues an ID that is thereafter sent to the application on every request. The ID would be stored in a cookie on the client-side, just like a regular session cookie. Since the frontend works through HTTP requests anyway it makes little sense to do it any other way to me.
Are there any better alternatives to this method that I should consider? I would prefer to keep the actual system completely decoupled from the web UI and also plan on implementing a desktop UI aswell, so the Interactor pattern seems to be the best way to achieve this to me. What I'm explicitly trying to avoid is the "do everything in our MVC framework! (and be stuck forever)" that seems to be popular nowadays.
Best Answer
I get what you're asking but the implementation you're describing is remote authentication, not session state. Session state doesn't care whether the user is authenticated or not. You don't want sessions to require authentication generally.
Regardless, back to the question:
What you are interested in is Distributed Session State. Traditionally, this is usually achieved by 1 of 2 main approaches:
A distributed cache cluster that the callers can access remotely. Particular softwares that do this really depends on what languages you are working with.
or
Sessions get persisted to a back-end database and interactions are handled by a service or other proxy-type interface.
The caching implementation is the fastest, as is the nature of reading from memory (even when distributed) but sessions are not persisted through restarts, shutdowns or failures.
The database implementation is a bit slower but is fairly fault-tolerant since they are persisted to the database. To compensate for the speed difference, database implementations usually use in-memory tables within the database, as it speeds up reads significantly and careful planning of indexing must be used (to many unneeded index changes causes the indexes to actually be counter-productive).
Another approach you could consider would be handling session state management like a web-based service. This would allow you to completely decouple sessions from the application and adhere to the mvc principle of maintaining statelessness. The service could be called via anything that can make http requests (even jQuery or ajax if you choose) and all responsibility could be pushed to the client (so you can have your cake and eat it too:))
I'm actually planning on trying the latter approach just to see how large it could be expanded (I've got my sights set on a HPC backend using Casandra db and aiming for a cloud-like structuring of session services).
Either way, any of these approaches will allow you to have sessions for any channels your application offers, including desktop :)