Space-Based Remoting

Remoting allows you to use remote invocations of POJO Plain Old Java Object. A regular Java object with no special restrictions other than those forced by the Java Language Specification and does not require any classpath. services, with the Space Where GigaSpaces data is stored. It is the logical cache that holds data objects in memory and might also hold them in layered in tiering. Data is hosted from multiple SoRs, consolidated as a unified data model. as the transport layer. Spring provides support for various remoting technologies. GigaSpaces uses the same concepts to provide remoting, using the Space as the underlying protocol.

Some benefits of using the Space as the transport layer include:

• High availability – the Space by its nature (based on the cluster topology) is highly available, so remote invocations get this feature automatically when using the Space as the transport layer.
• Load-balancing – when using a Space with a partitioned cluster topology, each remote invocation is automatically directed to the appropriate partition (based on its routing The mechanism that is in charge of routing the objects into and out of the corresponding partitions. The routing is based on a designated attribute inside the objects that are written to the Space, called the Routing Index. handler), providing automatic load balancing.
• Performance – remote invocations are represented in fast internal OpenSpaces objects, providing fast serialization and transport over the net.
• Asynchronous execution – by its nature, remoting support is asynchronous, allowing for much higher throughput of remote invocations. OpenSpaces allows you to use asynchronous execution using Futures, and also provides synchronous support (built on top of it).

The OpenSpaces API supports two types of remoting, distinguished by the underlying implementation used to send the remote call. The first is called Executor-Based Remoting, and the second is called Event-Driven Remoting.

Choosing the Correct Remoting Mechanism

This section explains when you should choose to use each of the remoting implementations. As far as the calling code is concerned, the choice between the implementations is transparent and requires only configuration changes.

In most cases, you should choose Executor-Based Remoting. It is based on the GigaSpaces Task Executors feature, and executes the method invocation by submitting a special kind of task that executes on the Space side by calling the invoked service. This option allows for synchronous and asynchronous invocation, map/reduce style invocations, and transparent invocation failover.

Event-Driven Remoting supports most of the above capabilities, but does not support map/reduce style invocations. In terms of implementation, it's based on the Polling Container feature, which means that it writes an invocation entry to the space which is later consumed by a polling container. Once taking the invocation entry from the space, the polling container's event handler delegates the call to the space-side service.

The Event-Driven Remoting implementation is slower than Executor-Based Remoting because it requires 4 Space operations to complete a single remote call: write invocation entry by client –> take invocation entry by polling container –> write invocation result by polling container –> take invocation result by client. In contrast, Executor-Based Remoting only requires a single execute() call.

However, there are two main scenarios where you should opt for Event-Driven Remoting over Executor-Based Remoting:

• When you would like the actual service not to be co-located with the Space. With Executor-Based Remoting, the remote service implementation can only be located within the Space's JVM Java Virtual Machine. A virtual machine that enables a computer to run Java programs as well as programs written in other languages that are also compiled to Java bytecode.(s). With Event-Driven Remoting, you can put the client on a remote machine and use the classic Master/Worker pattern for processing the invocation. This offloads the processing from the Space (at the expense of moving your service away from the data it might need to process).
• When unexpected bursts of invocations are a probable scenario, using Event-Driven Remoting may prove worthwhile, because invocations are not processed as they occur; they are "queued" in the Space and are processed by the polling container when resources are available. By limiting the number of threads of the polling container, you can ensure that the invocations don't monopolize the CPU of the Space. (The Alerts API can help monitor this situation.)

Additional Resources