Migrating to Open Spaces

Added by Shay Banon, last edited by Aleia Hutcherson on Jul 02, 2008  (view change)
  General Resources

API Docs
Forum
Downloads
White Papers
gigaspaces.com     

                                               
Summary: Moving from Spring Modules and space worker support to Open Spaces.

Migrating from Space Worker (IWorker)

The space worker allows you to run your business logic in the space JVM.

5.2 Usage

IWorker implementations are configured in the space configuration file, and controlled by the space.

6.0 Usage

In version 6.0, it is possible to:

  • Use the space worker as in version 5.2 – the IWorker can be easily used in an Open Spaces environment. The Space element or space creation in Open Spaces loads a space that can have several workers configured inside its schema.
  • Use Open Spaces (recommended) – IWorkers are not the preferable way to program IWorker-like functionality. It is recommended to use Open Spaces, which provides IWorker features and capabilities, and more.

Detailed below are the features gained when using IWorker, and how each feature can be obtained in version 6.0 with Open Spaces.

Collocation of Business Code and Data

5.2 Usage – IWorker

Since IWorkers are controlled by the space, they are started and injected with an IJSpace instance, allowing you to access the space in a collocated manner.

6.0 Usage – Open Spaces

When using Open Spaces, the same behavior is achieved by using the Processing Unit (defined by a Spring application context), allowing you to create a space and its relevant beans inside a single JVM, and have them share the same lifecycle.

Primary/Backup Control

5.2 Usage – IWorker

A space worker can be configured to only be activated when the space is in primary mode. This is very important when the space worker works directly against a cluster member (since no operations can be performed directly on the backup space).

6.0 Usage – Open Spaces

With Open Spaces, it is very simple to be aware of the current space mode, since it is exposed as a Spring application event. Open Spaces also allows you to use simple beans in a single application context, to load them when the space is in primary mode, and to unload them when the space is in backup mode using the space mode context loader.

Last, all built-in Open Spaces components, such as the polling container and notify container, are primary/backup aware, and only operate (by default) on a space that is in primary mode.

Direct Access for a Cluster Member

5.2 Usage – IWorker

Space workers allow direct access to the cluster member they are started with. This allows for SBA behavior, where workers only work on their portion/partition of the data without leaving the Processing Unit boundaries.

6.0 Usage – Open Spaces

With Open Spaces, the GigaSpace component clustered flag allows you to specify if any access done through the mentioned interface will be performed on a clustered view of the space, or directly on a clustered member. The default value of the clustered flag also closely resembles a space worker, since in embedded spaces, it works directly with the cluster member.

Simple Example

5.2 Usage – IWorker

Here is a simple example of an IWorker that performs a polling take operation taken from the Hello SBA tutorial:

package com.gigaspaces.sba;

import java.text.SimpleDateFormat;
import java.util.Date;
import net.jini.core.lease.Lease;
import com.j_spaces.core.IJSpace;
import com.j_spaces.worker.IWorker;

public class MyWorker implements IWorker {
	private IJSpace space;

	SimpleDateFormat format = new SimpleDateFormat("hh:mm:ss.S");

	public void init(IJSpace _space, String arg1, String arg2) throws Exception {
		space = _space;
	}

	public void close() {
	}

	public void run() {
		MyEntry template = new MyEntry();
		try {
			while (true) {
				MyEntry msg = (MyEntry) space.take(template, null,Lease.FOREVER);
				System.out.println(format.format(new Date()) + " - " + msg.toString());
			}
		} catch (Exception e) {
			e.printStackTrace();
		}
	}
}

6.0 Usage – Open Spaces

In our case, we can use a polling container with our own event listener (we can use an annotation-driven adapter):

public class MyWorker {
    
	private SimpleDateFormat format = new SimpleDateFormat("hh:mm:ss.S");

    @SpaceDataEvent
    public void onEntry(MyEntry msg) {
        System.out.println(format.format(new Date()) + " - " + msg.toString());
    }	
}

Here is the Spring application XML that can be used:

<os-core:space id="space" url="/./space" />

<os-core:giga-space id="gigaSpace" space="space" />

<bean id="myWorker" class="eg.MyWorker" />

<os-events:polling-container id="eventContainer" giga-space="gigaSpace">
    
    <os-core:template>
        <bean class="eg.MyEntry" />
    </os-core:template>
    
    <os-events:listener>
        <os-events:annotation-adapter>
            <os-events:delegate ref="myWorker"/>
        </os-events:annotation-adapter>
    </os-events:listener>
</os-events:polling-container>

With these two definitions, we have achieved the same functionality that we have using a plain IWorker, and much more. We can now make use of all the features of the polling container in a declarative manner (through configuration). We can also, very simply, make use of the different Processing Unit containers that come with Open Spaces (especially the SLA-driven container) in a simpler manner.

If we look at the hello SBA example, we are actually done with the example, and deploying it is a very simple, without the need to worry about any other configuration/deployment files.

Migrating from Spring Modules

5.2 Usage

Since GigaSpaces 5.1, GigaSpaces provides a Spring integration using the Spring Modules project.

6.0 Usage

While this integration is still supported in GigaSpaces 6.0, it is preferable for new projects to use Open Spaces instead, and for current projects to start migrating to Open Spaces. Open Spaces provides numerous features on top of the current GigaSpaces integration using Spring Modules, and will be the official support for Spring integration down the road.

Open Spaces provides a rich Spring integration, allowing for a more intimate integration with GigaSpaces, while exposing its extended features built on top of the JavaSpaces specification. Open Spaces also provides richer built-in components than the ones provided by Spring modules, while still maintaining a nice match with the current Spring modules components.

Open Spaces also addresses Spring/Processing Unit-based deployment which is not addressed when using Spring modules.

Space Creation

5.2 Usage – Spring Modules

When using Spring modules, creating a GigaSpaces IJSpace/JavaSpace instance was done in the following manner:

<bean id="space" class="org.springmodules.javaspaces.gigaspaces.GigaSpacesFactoryBean">
	<property name="urls">
		<list>
			<value>/./myCache?properties=gs&amp;</value>
		</list>
	</property>
</bean>

6.0 Usage – Open Spaces

With Open Spaces, creating a Space is done in the following manner:

JavaSpaceTemplate and GigaSpace

5.2 Usage – Spring Modules

When using Spring modules, a JavaSpaceTemplate can be created on top of an actual space, allowing you to join existing transactions and handle exceptions. Defining a template is done in the following manner:

<bean id="javaSpace" class="...">
  ...
</bean>
<bean id="spaceTemplate" class="org.springmodules.javaspaces.JavaSpaceTemplate">
	<property name="space" ref="javaSpace"/>
</bean>

6.0 Usage – Open Spaces

With Open Spaces, the equivalent of the JavaSpaceTemplate is the GigaSpace interface, and it can be constructed in the following manner:

GigaSpace also allows you to join existing transactions (including XA in 6.0.1), and translate exceptions. In addition, you can control if it will work directly with a cluster member or against the whole cluster, provides support for Generics and POJOs, allows you to configure various default values, and provides the basis for all other Open Spaces components.

Transaction Managers

5.2 Usage – Spring Modules

Spring modules comes with support for Jini Transaction Managers and GigaSpaces Local Transaction Managers. Here is an example of using a Jini Transaction Manager:

<bean id="javaSpace" class="...">

<bean id="jiniTransactionManager" class="org.springmodules.jini.JiniServiceFactoryBean">
	<property name="serviceClass" value="net.jini.core.transaction.server.TransactionManager"/>
	<property name="timeout" value="10000"/>
</bean>

<!-- declaration of jini transaction manager -->
<bean id="transactionManager" class="org.springmodules.transaction.jini.JiniTransactionManager">
	<property name="transactionManager" ref="jiniTransactionManager"/>
	<property name="transactionalContext" ref="javaSpace"/>
</bean>

6.0 Usage – Open Spaces

Open Spaces supports both Local and Jini (mahalo/lookup) transaction managers as described in this section. Here is a simple example of how to configure a Local Transaction Manager (the most widely used transaction manager):

Open Spaces provides several features that allow you to extend and configure transaction management, including built-in support for JTA/XA in version 6.0.1.

Remoting

5.2 Usage – Spring Modules

Spring modules provides rudimentary support for remoting capabilities on top of the Space.

6.0 Usage – Open Spaces

Open Spaces provides a richer and enhanced solution, using its remoting support.

Labels

 
(None)