Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 8 ActiveSpaces Channel : Basic TIBCO ActiveSpaces Concepts and Terminology

Basic TIBCO ActiveSpaces Concepts and Terminology
This section provides a brief introduction to the ActiveSpaces concepts and terminology that are useful when working with the ActiveSpaces channel. See TIBCO ActiveSpaces documentation for more information.
Metaspace
A metaspace is a virtual entity that contains spaces, which are containers that store the data used by applications.
A metaspace is a container for managing system spaces, user spaces, and a group of members that are working together in a cluster. The metaspace is the initial handle to ActiveSpaces. An application or member first joins a metaspace, and through it, gets access to other objects and functionality.
A metaspace is created when the first process connects to it, and disappears when the last process disconnects from it. The metaspace grows or shrinks automatically as members connect to it and disconnect from it.
Initially, a metaspace contains only system spaces. As users create spaces in the metaspace, the definition of those spaces (along with other administrative data) is stored in system spaces.
Multiple metaspaces may exist at the same time, each one containing a completely independent set of spaces. This means, for example, that changes to a space called clients in a metaspace named Dev have no impact on a space named clients in a metaspace named Prod. Since no single application can connect to two different metaspaces using the same metaspace name, metaspaces should always use different names.
Space
A space provides shared virtual storage for data. A space is:
A shared entity. Many applications can access a space concurrently and each application has the same coherent view of the data contained in the space. The spaces in ActiveSpaces are called tuple spaces, and the items stored in them are called tuples.
A space can proactively notify applications of changes in the data contained in the space as changes happen (push model), and can therefore be used as a coordination mechanism for building distributed systems.
A virtual entity that is distributed and implemented collaboratively by a group of processes located on multiple hosts and communicating over the network.
ActiveSpaces handles changes in this set of processes automatically: processes may join or leave the group at any time without requiring any user intervention. A space automatically scales up as the number of processes in the group increases, and scales down when processes suddenly disappear from the group or network. There is no negative impact on the data contained in the space when processes leave the space.
System spaces are a set of administrative spaces that are created and maintained by ActiveSpaces and are used to describe the attributes of the spaces.
User spaces are spaces that are defined by the user.
Members and Member Roles
Entities that need access to a space join the space as members.
Members can join a space as a seeder or as a leech:
Seeders play an active role in maintaining the space by providing CPU and RAM.
Leeches play a passive role. They have access to space data but provide no resources.
Seeders
Seeder applications join the space and indicate their willingness to lend some of the resources of the host where they are deployed to scale the service provided by ActiveSpaces. In effect, the seeding applications have a portion of the Space embedded in their process.
ActiveSpaces distributes the data stored in the space evenly between all of the processes that have joined the space as seeders. ActiveSpaces is an elastic distributed system. Seeders can join and leave the space (effectively scaling it up or down) at any time without the need to restart or reconfigure any other participant in the space. When this happens. the distribution of entries is automatically rebalanced if necessary to maintain even distribution between the seeders.
Leeches
An application can also join a space as a leech, without contributing any of its host's resources to the scalability of the space, and without experiencing any limitation in functionality or in its ability to use the space. A leech (as opposed to a seeder) is a peer of the space that is not considered by the distribution algorithm and therefore can join or leave the space without causing redistribution of the data.
ActiveSpacesSerializer
The default serializer used to deserialize ActiveSpaces tuple to a simple event in TIBCO BusinessEvents and to serialize an event in TIBCO BusinessEvents to an ActiveSpaces tuple. You must configure the serializer (com.tibco.cep.driver.as.serializers.ActiveSpacesSerializer) for every destination created on the ActiveSpaces channel.
Distribution role
The distribution role (Seeders or Leeches) is a level of participation of a space member and does not indicate any limitation on use. Leeches have access to the same set of space operations as seeders. The choice of distribution role must be made on a per space basis: it may be that the best solution is to join some spaces as a seeder and others as a leech.
Consumption mode
ActiveSpaces can proactively notify applications of changes to the tuples stored in a space. You can choose one of the consumption modes: Event Listener or Entry Browser.
When the consumption mode of a destination is event listener, the destination behaves like a subscriber in a publish-subscribe messaging system. When certain data changes or certain events occur, a callback function is invoked. You can choose the type of events to listen to: Put Event, Take Event, and Expire Event.
When the consumption mode is entry browser, the destination can monitor the space for data changes or certain events to occur, and can retrieve the tuple from the space using the browser type - Get or Take.
Tuple
A tuple is similar to a row in a database table: it is a container for data. Specifically, it is a sequence of named elements called fields (similar to the columns in a database table) which contain values of a specific type. Each tuple in a space represents a set of related data.
Fields have a name and a type. A tuple can be seen as a kind of map on which fields can be 'put' or 'removed'. A tuple can also be seen as a self-describing message. Tuples are platform independent, and can be serialized and deserialized.
Filters
Filters can be applied to both listeners and browsers, and also be used to evaluate a tuple against a filter. Filters allow your application to further refine the set of tuples it wants to work with using a space browser or event listener.
A filter string can be seen as what would follow the where clause in a select * from Space where… statement.
Examples
   field1 < (field2+field3)
   state = "CA"
   name LIKE ".*John.*" //any name with John
 
Filters can make reference to any of the fields contained in the tuples. Filters do not provide any ordering or sorting of the entries stored in the space.
Operators Supported in Filters
Table 19 shows the operators that are supported in the ActiveSpaces filters:
modulo, as in ( MOD (x,y) or x % y)
range, as in “age in (1,3,5,7,11)"
only used with NULL or NOT NULL, as in “x IS NULL" or "x IS NOT NULL"
nor, as in “age NOT 30 NOR 40“
Formats for Filter Values
Table 20 shows the formats for values used in filters.

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved