Continual Live - moving continuous integration on a step

Another, more technical, element that SOA can enable is that of "continual live" which builds on the concepts of continuous integration but moves more towards a continual simulation and system test approach rather than focusing on unit testing. The basic principles of Continual Live are pretty simple

1. Define Service Interfaces first
2. Define a formal contract for the service interface
   
3. Implement a Mock implementation with explicit known behaviour

This means that any other Service that depends on this one is able to make a functional call and have a result returned. An example would be a "AccessManagement" Service which determines whether a user is allowed to access a given piece of functionality. First its interface would be defined with a contract, and then a Mock implementation that always returns "true", this enables other services to then be built which can call AccessManagement and test that they are making the call.

The contract element is the trickiest, its something we've had a crack at with Obligate but that is just for Java and its early days, as there aren't any real approaches for that so 2 is currently an optional step for most projects. You do still get value from doing continual live.

This means that once you have defined all your services you are able to deploy the whole application to a server and run some system tests. Depending on how you set up the mock implementations these tests could all pass or all fail, most likely (if you've written decent tests) some will pass and others will fail. Assuming that you write decent tests this means that over time as services are implemented the number of failed cases is reduced. Because services are actually calling other services this means that the tests are more system test in nature rather than being unit test, this approach also means that as you start putting screens on the system you don't have to stub out calls that "haven't been implemented yet" you can write the code as required and demonstrate a running environment much earlier in a project.

Tools like cruise control and ant can be easily extended to support a continual live approach, the key change is that instead of just writing unit tests (which should continue, especially when you don't have contracts) you can also write system tests. If you are using a contract based environment then unit tests become less required and its actually the system tests that matter more, as the contracts will enforce the validity of operation of the service.

So basically, Continual Live is about getting a "running" system up as early as possible to help identify inter-service problems based on actual invocation and to track the evolution of the system. If combined with contracts it provides a pretty cheap way to build very robust systems and identify clearly who is causing the problems.