Here’s a use case:
I have a desktop application (built using Eclipse RCP) which on start, pops open a dialog box with ‘UserName’ and ‘Password’ fields in it. Once the end user, inputs his UserName and Password, a server is contacted (a spring remote-servlet, with the client side being a spring httpclient: similar to the approaches here.), and authentication is performed on the server side.
A few questions related to the above mentioned scenario:
- If said this authentication service were to go down, what would be the best way to handle further proceedings? Authentication is something that I cannot do away with. Would running the desktop client in a “limited” mode be a good idea? For instance, important features/menus/views will be disabled, rest of the application will be accessible?
- Should I have a back up authentication service running on a different machine, working as a backup?
- What are the general best-practices in this scenario? I remember reading about google gears and how it would let you edit and do stuff offline – should something like this be designed?
Please let me know your design/architectural comments/suggestions. Appreciate your help.
The simple answer is: Don’t let the authentication service go down!
Make sure your authentication service is running in a clustered, load balanced environment behind a virtual IP. That way, you can avoid downtime in the event that one of the individual servers goes down. This goes for not only the service itself, but any data sources that it relies on.
Obviously no system is completely fail-safe, but you should be able to get your uptime close enough to 100% that there is no need to build a “limited” mode for the desktop client.