A Space-based architecture (SBA) is an approach to distributed computing systems where the various components interact with each other by exchanging tuples or entries via one or more shared spaces. This is contrasted with the more common Message queuing service approaches where the various components interact with each other by exchanging messages via a message broker. In a sense, both approaches exchange messages with some central agent, but how they exchange messages is very distinctive.
An analogy might be where a message broker is like an Academic conference, where each presenter has the stage, and presents in the order they are scheduled; whereas a tuple space is like an Unconference, where all participants can write on a common whiteboard concurrently, and all can see it at the same time.
Tuple Spaces
each space is like a 'channel' in a message broker system that components can choose to interact with
components can write a 'tuple' or 'entry' into a space, while other components can read entries/tuples from the space, but using more powerful mechanisms than message brokers
writing entries to a space is generally not ordered as in a message broker, but can be if necessary
designing applications using this approach is less intuitive to most people, and can present more cognitive load to appreciate and exploit
Message Brokers
each broker typically supports multiple 'channels' that components can choose to interact with
components write 'messages' to a channel, while other components read messages from the channel
writing messages to a channel is generally in order, where they are generally read out in the same order
designing applications using this approach is more intuitive to most people, sort of the way that NoSQL databases are more intuitive than SQL
A key goal of both approaches is to create loosely-coupled systems that minimize configuration, especially shared knowledge of who does what, leading to the objectives of better availability, resilience, scalability, etc.
More specifically, an SBA is a distributed-computing architecture for achieving linear scalability of stateful, high-performance applications using the tuple space paradigm. It follows many of the principles of representational state transfer (REST), service-oriented architecture (SOA) and event-driven architecture (EDA), as well as elements of grid computing. With a space-based architecture, applications are built out of a set of self-sufficient units, known as processing-units (PU). These units are independent of each other, so that the application can scale by adding more units.
The SBA model is closely related to other patterns that have been proved successful in addressing the application scalability challenge, such as shared nothing architecture (SN), used by Google, Amazon.com and other well-known companies. The model has also been applied by many firms in the securities industry for implementing scalable electronic securities trading applications.
History
Space-based architecture (SBA) was originally invented and developed at Microsoft in 1997–98. Internally at Microsoft it was known as Youkon Distributed Caching platform (YDC). The first large web projects based on it were MSN Live Search (released in Sept. 1999) and later MSN Customer marketing data store (multi-terabyte in-memory DB shared by all MSN sites) as well as a number of other MSN sites released in late 1990s and early 2000s. See US patents 6,453,404 and 6,449,695:
[1][2]
and other patents based on these:[3]
Components of space-based architecture
An application built on the principles of space-based architecture typically has the following components:
Processing unit
The unit of scalability and fail-over. Normally, a processing unit is built out of a POJO (Plain Old Java Object) container, such as that provided by the Spring Framework.
Virtual middleware
A common runtime and clustering model, used across the entire middleware stack. The core middleware components in a typical SBA architecture are:
Component
Description
Messaging grid
Handles the flow of incoming transaction as well as the communication between services
Manages the data in distributed memory with options for synchronizing that data with an underlying database
Processing grid
Parallel processing component based on the master/worker pattern (also known as a blackboard pattern) that enables parallel processing of events among different services
POJO-driven services model
A lightweight services model that can take any standard Java implementation and turn it into a loosely coupled distributed service. The model is ideal for interaction with services that run within the same processing-unit.
SLA-driven container
The SLA-driven container enables the deployment of the application on a dynamic pool of machines based on Service Level Agreements. SLA definitions include the number of instances that need to run in order to comply with the application scaling and fail-over policies, as well as other policies.
