• Service Provider Interface
• Specifying Different SPIs Per GridTask

Service Provider Interface

Service Provider Interface (SPI) design plays a key role in how GridGain is architected. From the initial stage GridGain was designed to fully "blend" into what we call a hosting environment. It is an important consideration because in many (if not in majority of) cases GridGain will not be deployed standalone but rather as part of bigger stack such as JEE application server, JSP/Servlet container or some other proprietary system like Tangosol Coherence.

SPIs allow GridGain to abstract out most of the fundamental low-level functionality, provide pluggable implementation capability and base the rest of the system on this functionality without depending on a specific implementation of it. Good comparison and the most direct analogy of this design is HAL (Hardware Abstraction Layer) used by all modern operating system to abstract them from the specifics of the particular hardware configuration.

SPI-based design along with the flexible configuration allows GridGain to start within these environments and fully utilize the services provided by them. Here are the few actual examples:

• Communication SPI allows GridGain to use JBoss HA facility when running in JBoss or Coherence protocol when running within Coherence for communication exchange
• Discovery SPI allows GridGain to use either JBoss HA or Coherence Clusteting when running in JBoss or Coherence for its topology and discovery functionality
• URI deployment SPI allows to configure GridGain to use the same deployment folder and model as hosting JEE server

GridGain comes with the following SPIs. We expect this list to grow as the product advances. Note that GridGain always comes pre-packaged with at least one default (and usually several) implementations for every SPI (in some cases like with communication and discovery SPIs GridGain comes with half a dozen of pre-built SPI implementations). Here is the list of all SPIs for GridGain:

SPI	Description	Multiple Support
Discovery	Responsible for discovery of new nodes and detecting failed nodes.	No
Communication	Provides capability to send and receive messages between grid nodes.	No
Collision	Provides job scheduling and collision resolution on remote nodes.	No
Failover	Provides pluggable grid job fail-over logic.	Yes
Topology	Provides pluggable topology management logic.	Yes
Load Balancing	Provides pluggable load balancing policies to distribute load between grid nodes.	Yes
Checkpoint	Provides an ability to save an intermediate job state.	Yes
Deployment	Responsible for deploying/undeploying tasks from different sources.	No
Event Storage	Provides storage for locally generated events.	No
Tracing	Allows to plug-in various external runtime monitoring solutions.	No
Metrics	Provides up-to-date node's telemetry information.	No

Specifying Different SPIs Per GridTask

Starting with GridGain 2.1 you can start multiple instances of GridTopologySpi, GridLoadBalancingSpi, GridFailoverSpi, and GridCheckpointSpi. If you do that, you need to tell a task which SPI to use (by default it will use the fist SPI in the list).

Add @GridTaskSpis ^Javadoc annotation to your task to specify which SPIs it wants to use. If this annotation is omitted, then by default GridGain will pick the first corresponding SPI implementation from the array of SPIs provided in configuration.

For more information and examples refer to Specifying Different SPIs Per GridTask documentation.