In Part I of this post-series I discussed the importance of testability in distributed systems and outlined a set of key principles for addressing the issue.
The truth is that testability is often constrained by the products that we're using. In this post I wanted to outline how we at GigaSpaces address these issue with OpenSpaces, our new Spring-based development infrastructure:
Start with the architecture
There are a few components in OpenSpaces and Space-Based Architecture that significantly simplify the distributed architecture complexity:
Processing-Unit: unifies the deployment, scaling and fail-over behavior semantics of both the middleware and business logic components.
In-Memory Middleware: OpenSpaces takes advantage of the fact that space-based middleware can address both messaging and data using the same underlying technology. That in itself reduces a large part of the complexity, because we reduce the amount of moving parts in our architecture.
The fact that "spaces" can be collocated in-memory reduces the runtime footprint and provides a simple way for running the entire application in a single process environment.
Spring Abstraction – The Spring Framework was primarily designed to address the complexity of J2EE applications. OpenSpaces utilizes and extends many of the principles introduced by Spring, such as dependency injection and separation between the business logic and the underlying implementation through abstraction, remoting, etc. This simplifies the architecture and configuration of an OpenSpaces-based distributed application.
Measure scalability and fail-over as part of the unit-test environment
Because OpenSpaces is a relatively lightweight framework, it is easy to start an entire cluster within a single Eclipse session. This allows to very easily measure the behavior of the application in fail-over and scaling scenarios.
Enable fast iterative development
The concept of the Processing Unit allows developing all of the business logic in a single VM and running it locally. Moving it to a cluster, and scaling it, only requires to run that *same* processing-unit multiple times. This makes the production and unit-testing environments pretty much one and the same, and therefore, enables testing 90% of the functionality in a single environment. OpenSpaces helps you to take advantage of that and enable the developer to deploy the application from his or her testing environment to the production system by a click of a button, knowing that it's going to behave the same as in the local environment.
Keep the configuration consistent
In this respect, OpenSpaces provides a standalone container that is tuned to run within an Eclipse environment. Using this approach, a user changes only the container used between the development and production testing environment, while the rest of the code and configuration remains the same.
