Why should I use TupleSpaces?

TupleSpaces are an easy and elegant way to implement blackboard architecture. The idea of a blackboard architecture is to have a central place for data exchange (the blackboard), where all participating clients "meet" and coordinate. Since all clients only communicate over the blackboard and the coordination is only done by using tuple signature (on which there needs to be an agreement before), this system is characterized by a very low amount of knowledge the clients need to have about each other. Such a loosely coupled system is quite robust, easily extendable and also simple to design.


Ok, TupleSpaces are nice, but why should I use SQLSpaces and not implementations that are better known?

There are several advantages of SQLSpaces in relation to other implementations. As a short summary you can say: SQLSpaces have a very straightforward and easy-to-use API, while they have a lot of features that others don't have. A detailed comparison can be found in the How-To.


If SQLSpaces are built on top of a relational database, why not use a database directly?

Yes, SQLSpaces are using a database, but they are also adding many features on top of just storing rows of data. This level above the databases lets you forget tables, indices and foreign keys and gives you features like easy notifications, expiration, versioning, extended query mechanisms, etc. Of course you could use a database as a backbone for a distributed system, but SQLSpaces will give you many useful features for free and let you think in a more abstract way about your coordination and data exchange challenges.



Why don't you have a client for [my favorite programming language]?

The clients that are currently available were all developed for certain use cases. If we don't have a client in a particular language simply means, we didn't need it, yet.

However, it is quite simple to write a client for the SQLSpaces, because the protocol between client and server is XML-based. If you are interested in writing a client on your own, please contact us and we will give you the necessary XML schemas.


What do I have to do before I can run the server? Do I have to install something?

Since SQLSpaces are using a database internally, you need a database on your machine. It is recommended to use MySQL, which needed to be installed first, but together with SQLSpaces the free Java database system HSQLDB is delivered that can be used without any installation effort. As a matter of fact, SQLSpaces' default configuration uses HSQLDB, so you can just download the bundle, unzip it and run it.

However, please keep in mind, that you still need to have a Java Runtime Environment (1.5 or higher) on your machine.


How can I access the server if it is behind a firewall?

SQLSpaces are using several ports for communicating:

  • 2525: The most important port, since all client communication is done over this port. This has to be accessible!
  • 2530: Communication port for SSL-secured connections. Disabled by default.
  • 2535: Port for remote monitoring and controlling of the server. Mainly used by the Vizard and the investigator. Activated by default.
  • 2540: Access port for the SQLSpaces shell that gives you a console interface for querying and controlling the server. Disabled by default.
  • 8080: The internal web server runs here. If you want to use the investigator, this port has to be accessible. Activated by default.

The easiest way to activate, deactivate and change all these ports is editing the sqlsconfig.properties file (see How-To).



When should I use different spaces?

The disjoint sub-spaces are actually only for one specific purpose and that is to separate tuples from each other. There are several reasons why this might be useful.

In the most obviuos case in which this is useful there are several independent systems that all run on the same SQLSpaces server. To ensure that they really run indepently a separation of the spaces is necessary to avoid unwanted interferences between the systems. Otherwise it might very well be possible that one system grabs the tuples of another and thereby producing inconsistent states.

However, also inside one application it might be appropriate to use several spaces. Whenever you want to have disjoint, but similar categories in your system, like user sessions or production levels, you can use spaces to guarantee independence. However, this independence can also be achieved by using so-called marker fields, which are just strings in the beginning of a tuple that indicate which kind of tuple this is, e.g. a session ID. Keep in mind that more spaces will make it more complicated to get information from different spaces.


I have quite complex data structures. How should I map them to tuples?

This of course heavily depends on the situation, but here are some general hints from us:

Scramble them down: If it is possible, flatten the structure until you have a plain list that can be "tupleized". If this list is of variable length, you can still use wildcard fields to formulate queries.

Extract important fields: If you have e.g. a complex XML structure, don't just put this into an XML field, because you cannot query on this one very well. Better create a tuple with some relevant information from the XML node in the first few fields and then append the whole XML structure. By doing so, you can nicely query these tuples and still have the whole XML tree for further procession steps. In future releases an XPath query is planned, but until then XML fields cannot be queried well.

Don't use tuples as blobs: Yes, you can put arbitrary binary data into tuples, but remember that this cannot be used for querying and you mostly also loose the multi-language support.


I need to get notified if something happens. How should I best realize that?

There are two ways of immediately getting notified if something happened.

On the one hand you can use the waitToTake operation to block until a certain tuple is written into the space. This is usually done by simple agents that wait for requests. However, in this case the tuple is deleted from the space, so no other can take it afterwards. Furthermore your current thread blocks, so if there is anything else you would like to be done, you have to put this into a new thread.

On the other hand you can use callbacks for notifications. These are asynchronous calls from the server and therefore won't block your current thread. Moreover callbacks can be registered for write, update or delete events, whereas waitToTake of course only triggers, if someone has written a new matching tuple. A callback call itself doesn't delete the corresponding tuple, so if it should be deleted, you need to do a take after the callback. Also keep in mind that you need to care about the main thread in Java, if you just register callbacks. So if you find yourself writing code lines like

while (true) { 

you better stick to the waitToTake approach ...


Should I store the reference to the connection object by myself?

Yes, you have to! Please don't always call new Tuplespace() if you want to access a TupleSpace again, because each constructor call of the class TupleSpace will create a new connection! Just store the TupleSpace instance and hand it over to other objects that also need it. Only establish new connections, if it makes sense in your system. Please also use the method disconnect to gracefully finish the connection.



I still got other questions. Who will answer them?

If you have any questions, problems, feature proposals or similar don't hesitate to write us an email. Also if you are using SQLSpaces and have some thoughts you want to share or simply if your life as a programmer has become better since you are using SQLSpaces, just write us :)



How can I inform myself about new versions of the SQLSpaces?

Follow us on Twitter!