Distributed web architecture with Spring

Overview
I have been working on a fairly interesting distributed architecture for some time now and this post describes this work. What makes this architecture interesting is the use of AOP to externalize coordination and communication between a various instances of the same server.

In this architecture a server can run in either:

• Single mode - in this mode the server encompass both the master and slave modes
  
• Master mode - in this mode the server serves as the main entry point for requests. A master can interact with several slaves depending on availability
  
• Slave mode - in this mode the server is serving as a slave awaiting requests from a master
  

A server running in single mode is what we typically understand when we talk about a server. It really only becomes interesting when we are breaking this server up into a distributed topology. All extra logic to handle the difference between these is handled by aspects. The master is the central coordinator in this configuration and dispatches requests to a potential slave when needed. The master contain all information on what requests to handle locally or which ones to dispatch to a slave.

AOP interceptors are used to handle the extra logic that has been extracted from the master and slave. Both method interceptors and request interceptors are used. The method interception is used for things like user creation, user update, invitation and registration. The request interception is used for functionality that should be handled by a slave.

This type or implementation gives a lot of flexibility in that once the single server is implemented the master and slave specifics are added on top as aspects. This makes the architecture easy to configure and modify. The architecture has been made modular such that the master and slaves together forms a single server that is driven by a single interface via a web browser.

The request dispatching mechanism cooperates with Registry in order to dispatch the slave specific requests. The configuration of these requests is stored in a application context configuration. The UI is constructed on the master/single server but individual requests are processed based on the request configuration. To make it simple, it is assumed that all requests are processed by the master/single server unless configured to be processed by a slave. What slave to dispatch the request to is dynamically determined by the Registry. All slave servers registers with a central master server upon startup.

Once a user logs onto an master, a session is also created with the slave associated to that user. The session is stored in the registry. The slave to authenticated against is defined during user registration where the slave is determined.

Both the master and slave server stores the same user information. This is needed in order to be able to handle all the various use cases.

The beauty of aspects I that they can be applied to code to add new functionality that was not originally thought of. Code or functionality can be decorated with new functionality. Another powerful benefit with aspects is that they allow for common code that crosscuts different conceptual areas to be externalized and thus be shared which reduces the amount of code that has to be written.