Summary: This section deals with the internals of the GigaSpaces XAP packaging and deployment unit, namely the processing unit. It explains how to create it and how to run it in the various runtime modes.

Overview

The processing unit is the unit of packaging and deployment in the GigaSpaces XAP platform.

This section details the anatomy and details of the processing unit. It describes the various processing unit types, explains its directory structure, deployment descriptor, SLA attributes and how you can debug, run and deploy it on to the GigaSpaces XAP runtime environment.

Processing Units - The Packaging & Deployment Unit

GigaSpaces applications are composed of one or more processing units. Generally speaking, a processing unit is simply a folder which contains your application assembly (dll) files, any files it depends on, and a deployment descriptor.
A processing unit configuration is actually an application configuration file (similar to app.config or web.config) with GigaSpaces-specific xml elements to reflect the GigaSpaces specific attributes of the processing unit. In addition, a processing unit defines its Service Level Agreement (SLA).

The SLA can determine the amount of processing unit instances, the deployment constraints for it (e.g. specific IP range), the topology of the data grid contained in it (see below) and more.

When a processing unit is deployed to the GigaSpaces runtime environment, one or more processing unit instances are created and provisioned to the running GigaSpaces containers. The amount of processing unit instances depends on the configuration of the processing unit.

In general, there are 3 types of processing units: Data only, business-logic only and mixed processing units (which contain both data and business logic). The data container for processing units is GigaSpaces' in memory data grid (IMDG) implementation, which is called the Space.

The space can be accessed via various APIs, and can be deployed in multiple topologies (which determine how the data is distributed across the cluster). It can be replicated (in which case the objects written to it are replicated across the cluster) or partitioned (in which case objects are distributed across multiple instances). If it's partitioned, it may also have backups for each partition.

Data only processing units

This type of processing units does not include any business logic, only a Space. The processing unit simply defines the runtime characteristics of the space, i.e. its runtime topology, the number of space replicas/partitions, etc.

Business-logic only processing units

This type of processing units include only your application's code. Typically, your code interacts with a remote Space (defined by another processing unit), but that's not mandatory.

Mixed processing units

This type of processing units includes both business logic and a space. Typically, the business logic interacts with a local space instance (i.e. an data grid instance running within the same processing unit instance) to achieve lowest possible latency and best performance.

In such processing units, the processing unit state is directly related to that of the space instance it contains. If the space instance is in backup mode, the entire processing unit is in backup mode, which means that the business logic services which access the local space are not active. Upon failover, when the backup becomes primary, the business logic services also kick in and start working.

The Processing Unit Structure

The Processing Unit folder follows a certain structure which enables the GigaSpaces runtime environment to easily locate the deployment descriptor and load its classes and the libraries it depends on. A typical processing unit looks as follows:

|--Processing Unit Folder
|----pu.config
|----sla.xml
|----MyCompany.MyProject.dll
|----3rdParty.dll

The processing unit is composed of several key elements:

  • pu.config (mandatory): This is the processing unit's deployment descriptor, which is in fact an Application Configuration File with a number of GigaSpaces-specific xml elements. These elements include GigaSpaces specific components (such as the space for example). The pu.config file typically contains definitions of GigaSpaces components (space, event containers, remote service exporters) and user defined components which would typically interact with those components (e.g. an event handler to which the event containers delegate the events, or a service component which is exposed to remote clients by a remote service exporter).
  • sla.xml (not mandatory): This file contains SLA definitions for the processing unit (i.e. number of instances, number of backup and deployment requirements). Note that this is optional - if not present, the default SLA will be applied. SLA definitions can be also specified at the deploy time via the deploy CLI or deploy API.
    SLA definitions are only enforced when deploying the processing unit to the GigaSpaces service grid, since this environment actively manages and controls the deployment using the GSM. When running within your IDE or in standalone mode these definitions are ignored.
  • User assembly files: Your processing unit's classes (here as MyCompany.MyProject.dll)
  • 3rd Party files: Other files on which your processing unit depends (e.g. logging libraries, persistence frameworks).

Deploying the Processing Unit to the GigaSpaces Service Grid

When deploying the processing unit to GigaSpaces Service Grid, the processing unit folder is uploaded to the GigaSpaces Manager (GSM) and placed at the Deploy directory of the local GigaSpaces installation (located by default under <GigaSpaces Root>\Deploy).

Once uploaded, the GSM processes the deployment descriptor and based on that provisions processing unit instances to the running GigaSpaces containers.

Each GSC to which a certain instance was provisioned, downloads the processing unit folder from the GSM to its local work directory (located by default under <GigaSpaces Root>\Work\deployed-processing-units) and starts the processing unit instance.

Section Contents

GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence