Deploying and Running

This section describes the various options for debugging and running your Processing Units This is the unit of packaging and deployment in the GigaSpaces Data Grid, and is essentially the main GigaSpaces service. The Processing Unit (PU) itself is typically deployed onto the Service Grid. When a Processing Unit is deployed, a Processing Unit instance is the actual runtime entity..

In production, your Processing Units run on the GigaSpaces service grid, taking advantage of its SLA and monitoring capabilities. However, when developing your application, you typically want to run it from within your IDE Integrated Development Environment. A software application that helps programmers develop software code efficiently. It increases developer productivity by combining capabilities such as software editing, building, testing, and packaging in an easy-to-use application. Example: DBeaver. or in a more lightweight mode that will not require you to start a complete runtime environment.

The abstraction that enables running the same Processing Unit in different modes (service grid, within your IDE, etc.) is called Processing Unit Containers.

Naturally, the Grid Service Container implements its own Processing Unit container, allowing for Processing Units that are provisioned to it to run properly.

In addition, to facilitate easier development and debugging, GigaSpaces provides two more Processing Unit containers. The Integrated Processing Unit Container allows you to debug and run your Processing Units within your IDE in an isolated, easy-to-use mode. The Integrated Processing Unit Container is simply a class with a main method, which instantiates a Spring application context for your Processing Unit and makes sure other services (such as cluster information) is available to your code as if it was running in a real cluster.

Similarly, the standalone Processing Unit container also runs your Processing Units in a simple isolated environment, allowing you to start and stop them quickly to avoid the overhead of starting a full-blown cluster.

Both the Integrated Processing Unit Container and the standalone Processing Unit run as a standalone Java process, and therefore cannot enforce any of the SLA requirements of the Processing Unit. Their primary purpose is to enable you to debug and unit test your Processing Units.

Choosing the Correct Runtime Mode

The following table summarizes when to use each of the runtime modes.

You Would Like to...	Runtime Mode	Processing Unit Container Name
Unit test your Processing Unit within your IDE	Embedded in IDE	Integrated Processing Unit Container
Unit test your Processing Unit or run it in an unmanaged environment	Standalone	Standalone Processing Unit Container
Run your Processing Unit in production or conduct full-blown integration tests	Managed by the Service Grid	Service Grid A built-in orchestration tool which contains a set of Grid Service Containers (GSCs) managed by a Grid Service Manager. The containers host various deployments of Processing Units and data grids. Each container can be run on a separate physical machine. This orchestration is available for XAP only. Processing Unit Container