GigaSpaces Spring architecture enables end-to-end dynamic scalability of stateful applications across the grid:

• Middleware Abstraction (DAO, JavaSpaces, transactions, JDBC, remoting, parallel processing, JMS) – enables a relatively non-intrusive approach to implementing business logic on top of GigaSpaces. Users can now leverage the rich functionality and simplification of the Spring framework, with the scalability of GigaSpaces.
• Service Abstraction – enables dynamic deployment of Spring beans into the grid.

• POJO2Entry converter – maps an existing POJO to the Data Grid. The approach is similar to the O/R mapping approach. Class metadata such as indexes, update mode, serialization mode and persistency mode can be added at the class or attribute level using Java annotation, or using the gs.xml files and the Spring XML configuration file.

  The POJO-Space support is an enhancement of the existing JavaSpaces interface.

• Transaction support – Spring provides a transaction abstraction layer that can be used to plug in different transaction implementations without changing the application code. GigaSpaces provides transaction support, through this interface, for both Jini Transaction and Local Transaction Managers.

For more details, see Spring Infrastructure Services.

JavaSpaces technology (see specification) is designed to solve two related problems: distributed persistence and the design of distributed algorithms. JavaSpaces services use RMI and the serialization feature of the Java programming language to accomplish these goals.

The Spring JavaSpaces template maps existing objects to the space, and allows JavaSpaces operations to use the Spring transaction abstraction behavior.

The GigaSpaces template provides extensions to the JavaSpaces template, including support for batch operations, enhanced notifications options, POJO support, optimistic locking, update semantics, count, clean, FIFO, security and more.

The advantages of using this approach are:

• Performance – an Object can be written to local space memory, while being synchronized in the background with a back-end database.
• Built-in clustering – data written to the space becomes immediately available to all instances holding DOA reference to this cluster.
• Advanced data distribution – data written to the space can leverage the existing data distribution topologies (partitioning, replication, master-local, etc.) without changing the application code. Applications can choose the appropriate distribution model at deployment.
• OO Support – since the space provides built-in POJO support, objects can be written directly to the space without going through any O/R mapping. The same objects can be queried using the SQL syntax, since the space implements a built-in indexing mechanism. Through the Hibernate Cache Plugin CacheStore (see: RDBMS Read-Through & Write-Through for: Map, JavaSpaces) plug-in, these objects can be stored in any database, with user-defined O/R mapping. Users can benefit from the performance and simplicity of the space model, while using Hibernate O/R mapping to map these objects to an existing database.

GigaSpaces provides JDBC support over Spring, allowing users to write code using standard SQL syntax. This same code will work with other JDBC-compliant implementations.

The opposite does not hold: migrating an existing JDBC implementation into this model requires a manual migration effort.

When this template is used, GigaSpaces behaves just like a standard JMS provider, through the virtual JMS implementation. Users already using JMS in their implementation will benefit from the data-virtualization capabilities GigaSpaces provides and from the ability to scale JMS-based applications using the partitioned GigaSpaces cluster.

The remoting interface is used to invoke a bean using a variety of pluggable transport implementations. Spring supports Remote Method Invocation (RMI), the Spring HTTP invoker, Hessian, Burlap or JAX RPC as the transport implementation, in addition to space-based remoting.

A space-based remoting implementation takes advantage of the space's high availability and implicit content-based routing semantics to enable scalable communication between different services. This provides the following benefits:

• Transparency – a call to space-based remoting looks exactly the same as any other remoting, so migrating to a space-based approach can be completely seamless.
• Reliability – the space ensures the execution of a method in several ways:
  • Retries
  • Durability – the request can be sent even if the service is not available.
  • Transactions – ensures consistency and recoverability in case the service fails during the execution of a certain operation.
  • Failover – a request is replicated to a backup space, which takes over if the space fails and ensures continuous high availability of the system.
• Transparent collocation optimization – through the embedded space topology, the service can be co-located or run as remote process. In case of local communication, the request goes through local references. When the service is distributed, it goes through the network. Since the space is a shared entity, both models can co-exist without changing the configuration: some service instances can be co-located and others can be remote. All this is transparent for the client application.
• Scalability – the same request can be targeted at multiple services, which compete to serve the request and share the load amongst themselves. Services can scale across the network dynamically, by monitoring the backlog (the amount of pending requests).
• Partitioning – requests can be partitioned based on class name and method argument. This ensures that requests with an execution-order dependency between them are routed to the same space instance, allowing the order of execution to be guaranteed. In this way parallelism can be achieved for stateful operations, not only for stateless ones.