Roughless Pragmatism or RP

Rule 1 of RP: Never paint yourself into a corner

This rule basically states that when you design software in an agile manner (i.e evolutionary design) always make choices that allow for maximum flexibility. This could translate to different things to different people and is really quite subjective. That is what is great and wonderful with software development, its so creative and yet technical and abstract at the same time.

Software development is all about having abstract thought models in your head. Its very unnatural to live in one reality (our dimension) and act in it based on another reality (some conceptually compatible, yet a very much simplified one.) This is where OO, DLS and so on comes in. Tons of stuff have been written about this :)

More rules will be posted as they are realized...

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.

Writing a book

I am very excited. I am back home in my home town in Sweden and met up with a really smart friend of mine from when I was younger. We dont meet up very often but when we do we always spend quite some time discussing various topics from politics to computer science and philosophy (often not leaving a single drop of Glenmorangie left.)

We have both been active working in the software industry for quite a few years now so you can imagine that our discussions can become quite animated when it comes to sharing our experiences.

For some time now I have been experimenting with the idea of writing a book about my exeriences in this field and how I feel about developing software and my passion for it. And as I mentioned this to my friend he got so interested that he suggested what we should do this in a joint fashion, and I though that was an excellent idea.

So we have now started this little project which I think will be a really cool one. I dont expect anything really other than it being a learning expericence for me/us. And as my former coworker (mr potatoehead) - "Frick", once explained to me, once you are explaining something to someone, you are focusing and structuring your thoughts in such a briliant way that the world is clear as mud.