Differences from traditional implementations.

Wikipedia gives an in depth discussion of what a Tuple Space is. SemiSpace's has a focus that is slightly different from the the traditional implementations as the space itself is not perceived to be separate from the client(s) VM(s). How you use it, is analogous, though. When having more than one VM, Terracotta takes care of the distribution.

SemiSpace does not use the concept of client and server. Rather, the space is distributed over the nodes present in the space.

Getter objects are supported as well as public fields. The JavaSpace standard only lets you play with public fields, which is a nuisance if you want to use (possibly) auto-generated Hibernate objects.

As long as your class can be streamed with XStream, you can put it into SemiSpace.

SemiSpace does not use Jini

SemiSpace does not require installation of a Jini server.

Jini is the crux of the standard JavaSpaces - which are the ones that implement the JavaSpace interface. Jini uses JERI, which is a re-implementation of RMI. JERI supports dynamic stub generation, which is useful if you are adhering to the client / server idiom.

The methods you find in the SemiSpace interface, however, are analogous to the methods you find in the JavaSpace interface. Presently JavaSpace05 is not considered. The differences between the SemiSpace and JavaSpace interface, is mainly that the transaction object has been removed, and that the return types may be different.

Terracotta is used for distribution

SemiSpace is bundled with a Terracotta Integration Module (TIM), which you can use in order to distribute the contents of your space. Besides distribution, you have the benefit of not having to create the configuration yourself.

SemiSpace uses XML

The transport and internal storage layer of SemiSpace is XML. This has the disadvantage of bloating and transformation, but the advantage of not needing any dependencies on Java objects when treating and using the space. This means that you can use the same space for several purposes without worrying about getting ClassCastExceptions.

When you are using Java code directly on the space, the XML layer is hidden, and you can concentrate on using the space in a manner which is the same as if you would use a Jini based implementation.

Query on first level depth

SemiSpace allows a nested object structure, but queries are only performed on the first level. This has the advantage have rather fat holder objects, whilst retaining the speed and functionality of the space. This make the space usable for caching.

This implies, however, that you should model the holder objects of the space carefully, preparing them with structures that contain record-like data, such as String and Integer. Large byte arrays, for instance, on the first level is discouraged as it becomes one of the fields that are used for identification - and as such is propagated over your servers.

All this implies:

• You can interface the space from different languages (such as Ruby) without having to think about Java Objects. The interfacing is performed with web services, in this case, and you will need to set up the web service end point.
• Java implementation on different nodes do not need to have the same libraries available.
• Use of SemiSpace is easy to junit test, as the space works well on a single VM.
• When distributing with Terracotta, you do not be too concerned abouttc-config.xml (the Terracotta configuration file).
• You can distribute Objects without taking the object depth into consideration. In other words, can you have arbitrarily large and / or nested objects. Only the first level is used in matching, though, and you still need to pay heed to network traffic overhead.