<<I hope to see the concepts behind space-based computing spreading to
a wider audience.
The "space-based" pattern proposed by GigaSpaces shares some qualities
with some other well-known solutions to scaling but adds some
interesting side-effects.

In my view, Space-based architecture can be compared to other
architectural choices that share some common qualities:

Transparent Partitioning and Co-location of:

1. Events
2. Work (logic and effort)
3. Data

Such a pattern might be dubbed TPC-based architecture. One of the
things I often mention when I speak about using spaces is the
reduction in mapping logic and effort when the space is used to enable
distributed applications.

For instance in many cases databases can be partitioned and can
contain stored procedures, giving them some of the TPC-based
architecture qualities.
In addition, databases are sometimes used as shared memory where the
primary pupose of a particular write to the database is to place some
data into a shared environment as a layer of interoperability between
application constructs.
The resulting mapping code between all the cooperating constructs to
and from the database can be a burden. (not to mention the overhead of
using a database for this purpose)
I have also seen databases used as a checkpoint mechanism for
transient data that has no long-term place in the system.
This use of a database as a state-management solution "guarantees"
reliability of state during a business transaction but at the cost of
extra code and extra connections to perhaps the wrong kind of resource.

When an application leverages a space or similar vehicle as the
state-management and interoperability platform, the constructs
involved are able to share Objects.

This can reduce the mapping issues often associated with other shared
resources. Reducing the lines of code you write.

Behavior exposed through those objects can also be leveraged in terms
of construction of legal instances and even work logic to be performed.

It is these additional things that begin to encompass the totality of
the space-based architecture.

As enabling technologies, our implementation of the TPC-based
architecture utilizes:

* Mobile code through a code-base enabled master-worker pattern
where tasks containing work can change over time and be routed to the
optimal location based on their state (allowing transparent
co-location and partitioning)
* Intelligent, Adaptive, Service deployment and runtime management
(allowing transparent yet deliberate co-location through our
declare-able clustering/co-location of managed services [not to be
confused with our space clustering]).
* An easy to configure and highly abstracted clustered JavaSpaces
implementation. (allowing transparent yet deliberate partitioning and
co-location of state, events and work)

Note the use of "Transparent" seems to focus on the developer role and
to what is visible to the author of the compile-able code artifacts.
"Deliberate" refers to the author of the non-compiled code such as the
various XML descriptors used to wire services together.

Orthogonal to the TPC-based architecture we have additional features
and benefits including:

* Integration with Spring (allows transparency of implemention)
* JDBC, MAP, JMS, HttpSession, etc APIs (allows increasing
transparency of implemention)
* Space API (allows extremely powerful and simple programming model)
* C++, .NET support (allows increasing transparency of language)
* policy-driven dynamic service management (allows additional
scaling and fault-tolerance for the entire system)>>

You can read this in full (including his plug for GigaSpaces:) at:

<http://jroller.com/page/owentaylor?entry=space_based_architecture_an_implementa\
tion>

Gervas