Overview – Simplifying Business Logic Abstraction
The GigaSpaces Spring integration plays a major part in GigaSpaces Write Once Scale Anywhere roadmap. It allows you to write your POJO once using Spring and scale it anywhere using GigaSpaces middleware. Spring provides a framework for implementing the application business logic, while GigaSpaces implements the middleware and service framework for executing this business logic efficiently, in a scalable fashion.
GigaSpaces Spring Architecture
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.
GigaSpaces maps specific Spring interfaces to the relevant GigaSpaces middleware component – the Data Grid, the Messaging Grid and the Parallel Processing engine (Compute Grid). This allows Spring-based applications to benefit from the performance, dynamic scalability and clustering capabilities of the GigaSpaces middleware without a complex development phase.
The middleware abstraction transparently converts POJOs to space Entries, and provides a transaction abstraction layer:
- 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.
- 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.
Data Grid Abstraction
There are two ways to access the Data Grid via Spring: the JavaSpaces and GigaSpaces templates, which map existing objects to the space and allow JavaSpaces operations to use the Spring abstraction behavior; and the JDBC template which allows users to write code using standard SQL syntax.
JavaSpaces and GigaSpaces Templates
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.|
GigaSpaces Spring integration provides messaging abstraction in two forms: a JMS template, which allows GigaSpaces to behave just like a standard JMS provider, and a remoting interface, which can be used to invoke a variety of pluggable transport implementations, including the powerful space-based remoting implementation.
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:
- 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.
Parallel Processing Abstraction
A special use for the remoting interface mentioned above is for parallel processing, in a similar way to the master-worker pattern used with the space.
In this case, each method call is a task, and each return value is a return on the task. Tasks can be executed by multiple service instances: each can be running on a different machine, leveraging its CPU power to increase processing capacity for serving that service. The end-user or client believe they are interacting with a single service.
Execution balancing is achieved through the space pull model: services block for requests, and if a worker is under load it simply pulls less requests; if it is underloaded, or is running on a more powerful machine, it simply pulls more requests.
Service Abstraction – Turning POJOs Into Distributed Services
Using the Service Grid, you can select a bean from a Spring bean descriptor file and deploy it onto the grid, scaling it dynamically by adding more instances of that service. You can also manage failover scenarios – for example, if one instance fails, the Service Grid automatically detects this and re-deploys it on another Container running at a different machine. It also automates the deployment procedure, selecting a machine that has the necessary Spring support out of the pool of available machines. If such a machine is not available, the Service Grid postpones deployment and re-deploys the service it as soon as one becomes available (for more details, see Developing and Deploying POJOs into Service Grid).
- About Spring Framework — An overview, architecture and basic usage scenarios of the Spring Framework (from Spring Reference Documentation).
- Spring Configuration Files — A sample application context file; attributes of the POJO's DAO definition; transaction configuration; supported operations and code sample for POJO primary key setting.
- Spring Data Grid Integration — Examples of the JavaSpaces Spring Template and JDBC Spring Template, two ways to access the Data Grid via Spring.
- Spring Infrastructure Services — GigaSpaces automatically converts POJOs to space Entries, and provides Spring support for local and distributed transactions.
- Spring Integration Implementation — Description of GigaSpaces Spring implementation classes: the factory bean; the Spring template; an extension of the JavaSpacesTemplate; and a local transaction factory bean.
- Spring Messaging Grid Integration — An example of a JMS application working with Spring in GigaSpaces.
- Spring Parallel Processing Integration — Sample implementation showing how to perform remote invocation for business logic of parallel processing units.