XAP

Space-Based Remoting

Remoting allows you to use remote invocations of POJOClosed 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 SpaceClosed 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:

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:

Additional Resources