COMP 4905 Honours Project Winter RSpace : A Tuple Space Implementation Using RESTful Web Services

Transcription

1 COMP 4905 Honours Project Winter 2014 RSpace : A Tuple Space Implementation Using RESTful Web Services Author: Paul Hayman Student #: Project Supervisor : Professor Tony White 1

2 Abstract RSpace is a lightweight and flexible implementation of a tuple space using RESTful web services. Existing implementations of a tuple space such as Javaspaces have many limitations. Javaspaces can only be accessed with Java and relies on Jini making it complex, slow and difficult to deploy. This project was created to eliminate the need for Jini and the use of Java to make a simpler implementation of a tuple space that is more practical for use in a distributed system. Creating a tuple space that can be interacted with through the use of RESTful web services also allows for access by different programming languages and can be used on mobile devices such as Android. 2

3 Acknowledgement I would like to thank my project supervisor Professor Tony White for all of his support and assistance from this project's concept to its execution. I would also like to thank my family for their continuous support. 3

4 Table Of Contents 1. Introduction...p.5 2. Background Information and Research...p Tuple Space...p RESTful Web Services...p JavaScript Object Notation...p.7 3. Design: Requirements, Considerations and Implementations...p RSpace Client Library...p Using Template to Find a Tuple...p Client Response Mechanism...p RSpace Server...p Server Queues...p The Listener Queue...p MongoDB...p Conclusion...p References...p.28 Appendix A : Testing...p.29 Appendix B : RESTful Interface Details...p.33 Appendix C : Setup Instructions...p.35 4

5 1 - Introduction RESTfulSpace (RSpace) is a lightweight and flexible implementation of a tuple space using RESTful web services. Existing implementations of a tuple space like Javaspaces can only be accessed in Java and rely on Jini making it complex, slow and difficult to deploy. This project was created to eliminate the need for Jini and the use of Java to make an implementation of a tuple space this is more practical and simpler for use in a distributed system. Creating a tuple space that can be interacted with through RESTful web services also makes it capable of being accessed by different programming languages and can also be used on mobile devices like Android. A tuple space is a form of distributed shared memory in which a tuple repository is provided that can be accessed concurrently. By accessing the tuple space, objects can be stored in and fetched from shared memory allowing for communication and synchronization in a distributed system. The RSpace project consists of two components: a server and client library. The server allows for concurrent access to the tuple space and is written in Java using Tomcat and Jersey. The client library, also written in Java, is used to access the space. 5

6 2.1 Tuple Space 2 - Background Information and Research Figure 1 : Coordination using a Tuple Space A tuple space is used to simplify communication and synchronization in a distributed system. It is a form of distributed shared memory in which a tuple repository (or tuple space) is provided which can be accessed concurrently through the use of producers, which post tuples to the space and consumers which retrieve tuples from the space. This allows multiple processes to concurrently share, access and modify objects in memory (tuples) in the shared repository. David Gelernter first introduced the use of tuple space as a way of simplifying communication in parallel/distributed systems in the form the Linda coordination language in his paper titled Generative Communication in Linda, in Initially there was a surge of interest in this model, but this decreased in the early 1990s. 2 More recently interest in the use of a tuple space re-surged and several implementations of a tuple space have been developed. One such implementation is JavaSpaces developed by Sun Microsystems. Although powerful, JavaSpaces has limitations as it is dependent on Jini which makes it 6

7 complex, slow, difficult to deploy and requires the use of the Java programming language. Further, it's client library is not usable on mobile devices such as Android. Through the use of RESTful Web Services as a means of accessing the tuple space, an implementation of a tuple space can be created that does not rely on Jini or the use of Java to access the space. 2.2 RESTful Web Services A web service is a method of communication over the World Wide Web. It is represented at a network address over the web which is always on, and contains software functionality which can be accessed using messages conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. 3 A large criticism of this form of communication is the numerous complex standards that have arisen around it. Tim Bray, one of the originators of the XML specification, has pointed out the length of these specifications is 783 pages in length. 4 Partly in reaction to this proliferation of standards, Roy Fielding proposed Representational State Transfer as a simpler alternative for the implementation of web services. 2 Representational state transfer (REST) is an architectural style by which you can design web services that focus on a system's resources. These resources, which may represent data or functionality, can be accessed and transferred over HTTP by a wide range of clients written in different languages. Because of its simplicity and its suitability to the functionality required for this project, RESTful web services were selected to allow clients to access the tuple space. 2.3 JavaScript Object Notation JavaScript Object Notation, or JSON, is used extensively in this project. It the data format that 7

8 is consumed by the RESTful endpoints and is used for the representation of tuple objects on the server. JSON is a lightweight data-interchange format that uses human-readable text to transmit data objects consisting of name-value pairs. It is used primarily to transmit data between a server and an application as an alternative to XML. JSON is language-independent, lightweight and is supported by a large variety of programming languages. 8

9 3 - Design: Requirements, Considerations and Implementations This project, RSpace, is an implementation of a shared tuple space that can be accessed concurrently across a distributed system through the use of RESTful web services. The RSpace project consists of a client library and a server. The client library, written in Java, is used to access the space. The server, written in Java using Jersey and Tomcat, maintains the repository of tuples and processes transactions initiated by clients accessing the space. The server uses MongoDB, a NoSQL database, as a back end for maintaining the tuple repository. Clients are able to interact with RSpace through it's client library in order to place tuples into the space and to retrieve them. A tuple will be returned when accessing the space if there exists a tuple in the space that succeeds in fulfilling the matching requirements based on the input given. 3.1 RSpace Client Library The client library for this project was written in Java, although implementations are possible in other languages because of the use of RESTful web service endpoints. The following methods can be invoked in the client library to access the tuple space: write(object tuple, long timeout) : places a new object into the space take(object template, long timeout) : retrieves object from a space read(object template, long timeout) : makes a copy of an object in the space Both take and read are blocking operations that will return a match when it is found in the space before a provided timeout length, or return null after the timeout has expired and no match is found. They each have variants takeifexists(object template) and readifexists(object template), which are non-blocking and do not require a timeout length as they immediately return a result whether a match is found or not. In other words, they are read and take operations with a timeout set to 0. If a match is not 9

10 found at the time these operations are called, theses methods will return null. For simplicity, these operations will be referred to as transactions and read, take, readifexists and takeifexists will be referred to collectively as responsive transactions Using Template to Find a Tuple The template provided as input for responsive transactions will be used to search for a desired tuple. If a match is not found before the provided timeout, the result of these calls will be null. A match will be found based on the following conditions: If a field in the template object is null, this is considered a wild card, and the tuple returned could have any value for that field. If a field in the template object is set to a particular value then the tuple returned will have an equal value in the same field. A successful match will return a tuple that is of the same class or a subclass of the template. A successful match will return a tuple that has not yet expired. Templates, therefore, can be created with no fields specified, all fields specified or some fields specified in order to retrieve a desired tuple. The class of an object to be written to the tuple space must have an empty constructor in order for it to successfully serialize to JSON as the JSON representation is what will be posted to the RESTful endpoints on the server. This is how a tuple will be represented on the server and all matching and storage will be done using the string that is the tuple's JSON representation along with the other various fields required when posting to the RESTful endpoint on the server. The tuple object must also not contain any primitive field types so that the default value for any field is null. Below is the TestObject class that will be used in the following simple examples. 10

11 public class TestObject { public Integer intfield; public String stringfield; public Boolean boolfield; TestObject(){ TestObject(Integer num, String string, Boolean bool){ intfield = num; stringfield = string; boolfield = bool; Example 1 using a template with no fields initialized public static void main(string[] args){ RSpace space = RSpace.getSpace(); /*write tuple to space*/ TestObject tupletowrite = new TestObject(99, "HelloWorld", true); space.write(tupletowrite, 30000); /*create uninitialized template*/ TestObject template = new TestObject(); TestObject result = (TestObject) space.read(template, 5000); /*show result as serialized JSON**/ Gson gson = new GsonBuilder().serializeNulls().create(); System.out.println(gson.toJson(result)); Output : {"intfield":99,"stringfield":"helloworld","boolfield":true As is demonstrated in the output, when calling read using a template where all fields are null, a tuple is returned with fields that could be set to any value. In this case it returned the tupletowrite object, as this was the only tuple in the space that was a match. Example 2 using a template with fields specified public static void main(string[] args){ RSpace space = RSpace.getSpace(); /*write tuples to space*/ TestObject tupletowrite1 = new TestObject(99, "HelloWorld", true); TestObject tupletowrite2 = new TestObject(33, "A String", false); space.write(tupletowrite1, 30000); space.write(tupletowrite2, 30000); /*create uninitialized template*/ 11

12 TestObject template = new TestObject(99, null, null); TestObject result = (TestObject) space.read(template, 5000); /*show result as serialized JSON**/ Gson gson = new GsonBuilder().serializeNulls().create(); System.out.println(gson.toJson(result)); Output: {"intfield":99,"stringfield":"helloworld","boolfield":true In this example, two tuples of the same class were written to the space with different values in their fields. A template object was created to search for any TestObject with intfield set to 99 and used to read from the space. This returned a tuple which is a copy of the object tupletowrite1, the tuple in the space that contained an equal value in the intfield. Another consideration when creating templates to retrieve tuples is that matching will occur no further than the top level of it's hierarchy. If a field of a template is an object, matching will not occur at the level of this embedded object. If the embedded object field of the template is set to null, it as a whole will be a wild card field and a matching tuple could have any variation of values in the fields of the embedded object. This is demonstrated by modifying the TestObject class to use an object as a field: Example 3 - modified TestObject with EmbeddedObject field : public class TestObject { public Integer intfield; public String stringfield; public Boolean boolfield; public EmbeddedObject obj; TestObject(){ TestObject(Integer num, String string, Boolean bool, EmbeddedObject myobj){ intfield = num; stringfield = string; boolfield = bool; obj = myobj; 12

13 EmbeddedObject class : public class EmbeddedObject { public String myembededstring; public Integer myembeddedinteger; EmbeddedObject(){ EmbeddedObject(String mystring, Integer myint){ myembededstring = mystring; myembeddedinteger = myint; Example 3 - attempt tuple match with wildcard fields set in EmbeddedObject : public static void main(string[] args){ RSpace space = RSpace.getSpace(); //write tuple to space EmbeddedObject embeddedtowrite = new EmbeddedObject("embedded", 99); TestObject tupletowrite = new TestObject(99, "HelloWorld", true, embeddedtowrite); space.write(tupletowrite, 30000); //create uninitialized template EmbeddedObject embeddedtosearch = new EmbeddedObject(null, 99); TestObject template = new TestObject(99, "HelloWorld", true, embeddedtosearch); TestObject result = (TestObject) space.read(template, 5000); //show result as serialized JSON Gson gson = new GsonBuilder().serializeNulls().create(); System.out.println(gson.toJson(result)); Output : null The object template with its EmbeddedObject field set as embeddedtosearch is used as a template to retrieve a tuple. The EmbeddedObject improperly contains a field set to null in an attempt to return the tupletowrite object that is written to the space. As expected, this returns null because the value of the field as a whole will be compared against tuples in the space for equivalency. The server will attempt to search the space for a tuple with an EmbeddedObject value that is equivalent to the template object. Note that the same results would be expected in this example if the template object had its 13

14 EmbeddedObject field initialized using its default constructor where all of its fields would be set to their default value null. To properly set the field as a wildcard the object must be null. Example 4 set entire EmbeddedObject as wild card public static void main(string[] args){ RSpace space = RSpace.getSpace(); //write tuple to space EmbeddedObject embeddedtowrite = new EmbeddedObject("embedded", 99); TestObject tupletowrite = new TestObject(99, "HelloWorld", true, embeddedtowrite); space.write(tupletowrite, 30000); //create uninitialized template TestObject template = new TestObject(99, "HelloWorld", true, null); TestObject result = (TestObject) space.read(template, 5000); //show result as serialized JSON Gson gson = new GsonBuilder().serializeNulls().create(); System.out.println(gson.toJson(result)); Output {"intfield":99,"stringfield":"helloworld","boolfield":true,"obj": {"myembededstring" :"embedded","myembeddedinteger":99 In this example, the field containing EmbeddedObject is set to null. The tuple that will be returned will be a tuple in the space that could have any variation of values for the fields contained in EmbeddedObject so a copy of the tupletowrite object is returned from the space Client Response Mechanism When a client calls read or take to retrieve a tuple, a timeout is specified. This allows the call to block until a time when a matching tuple is written to the space. A result of null will be returned when the timeout expires if a matching tuple was not written to the space in this time. This is achieved by first making an HTTP POST to the RESTful server endpoint for that transaction. This post contains the template and timeout provided, among other information, so the server can process the transaction. A mechanism had to be implemented so that the connection to the web service endpoint does not remain open for a long period of time while waiting for the resulting 14

15 tuple. Figure 2 : Responsive Transaction Mechanism For Client Figure 2 represents the interactions that occur when a responsive transaction such as a read is performed on the client. The RESTful endpoints for write, read, take, readifexists and takeifexists all consume a JSON string of the form : { "tuple": { "name": class name (string), "serializedtuple": JSON serialized tuple (string), "superclass": super class name (string), 15

16 "expirydate": date and time of expiry for transaction in milliseconds (long), "clientid": server generated Client ID (string) Where tuple contains the fields name : a String representing the template's class, serializedtuple : the JSON serialization of the template object, and superclass : a string representing the name of the template's super class. When one of read, take, readifexists or takeifexists is called from the client library, a thread is launched which creates and posts this JSON string to the appropriate server REST endpoint. The server's response to this post contains a unique transaction ID. This transaction ID is a unique ID for this call and will be used to inform the client which transaction has completed after the server returns a tuple result. After the thread receives this response, the transaction ID is used as a key and the thread itself is used as a value to be placed in a ConcurrentHashMap contained in the Responses class. After it is stored in the ConcurrentHashMap, the thread will wait for a tuple result from the server by using a CountDownLatch, a synchronization mechanism that is part of java.util.concurrent. When a transaction has completed on the server, the result is posted with a transaction ID to the Response class. The Response class then retrieves the thread from the ConcurrentHashMap using the transaction ID, provides the thread with the tuple result received from the server and notifies the thread to continue. After the thread is released from the CountDownLatch, the tuple result contained in the thread will be deserialized and returned to the original call invoked by the client. In order for the server to post a tuple result to the client, a RESTful web service endpoint is created when RSpace is initialized on the client. This endpoint is created using Restlet, a lightweight implementation of a REST framework. This endpoint remains open on the client waiting for processed transactions on the server to post their results as a JSON string in the form : 16

17 { transid : transaction id (int), clientid : client ID (string), serializedtuple : JSON serialized tuple result (string), classname : tuple result class name (string) The clientid field is a unique ID generated by the server on initialization of RSpace by the client. This ID is used as part of a solution to determine when a client has terminated. When a client terminates it should no longer affect the state of the shared space. The tuples it has placed in the space are removed, and any transactions on the server which have not completed are terminated. Because the server can't directly check whether or not a client is still active, a polling mechanism is used. When RSpace is initialized on the client, the URL of its RESTful endpoint and an expiry date are posted to a server endpoint to register the client. A unique ID is then generated and returned to the client. This client ID is then provided with each interaction the client makes with the server so the origins of the interactions are known by the server. The client then polls the server at a specified interval renewing the clients expiry date. When the client terminates it will fail to poll the server to renew itself and will expire. When the client expires the tuples it has placed in the space and transactions it has created on the server will also expire. The JSON string that is posted to the server's RESTful endpoints for registration and renewal is of the form: { "clientid": client ID (string), "url": url for posting tuple results to client (string), "timeout": date for expiry in milliseconds(long) 17

18 3.2 RSpace Server The RSpace server represents the tuple space shared among the distributed system. RESTful web service endpoints are exposed to the client library so it can interact with the shared space. There are separate endpoints for each operation a client can perform when interacting with the space, i.e read, take, write, takeifexists and readifexists. When a client posts to these endpoints, a transaction for the request is created based on the type of operation. Two other endpoints are available for registering the client and renewing the client, allowing the server to maintain a list of the active clients and the URL for returning tuple results. The server uses a database to maintain the tuple repository and active clients. Processing that occurs between the endpoints and the tuple repository is coordinated through a series of queues. Each queue has a specific role and processes the transactions at some stage before a result is received by the client Server Queues The TransactionQueue and ResponseQueues are classes containing static instances of a LinkedBlockingQueue which hold Transaction objects that contain the functions and information necessary to complete their operations. When initialized, these classes launch a worker thread which continuously reads new Transactions off their queue and completes their processing for that stage. The ListenerQueue is slightly more complex and is described in further detail in section After a client has posted to a particular RESTful endpoint, the appropriate Transaction object is created and placed immediately in the TransactionQueue. A TransactionWorker waits for new transactions to be added to the queue. When a new transaction is added the TransactionWorker removes it from the queue invokes the perform() method. This method interacts with the database to perform the 18

19 required operations for the specific type of transaction. Based on the result of this operation on the database, the transaction will be placed in either the ResponseQueue or it will be placed in the ListenerQueue. If the transaction has completed, because a read transaction has found a matching tuple or has timed out, it is placed in the ResponseQueue where the tuple result is returned to the client. If a transaction is not complete, because a read transaction did not find a match and has not yet timed out, it is placed in the ListenerQueue where it will find a matching tuple if it is added to the tuple respository at a later time, or after the timout expires return a result of null. Figure 3: Processing Responsive Transactions A ResponseWorker listens for new Transactions to be added to the ResponseQueue and when a new Transaction is added it obtains the tuple result for that transaction as well as other necessary data for posting to the clients RESTful endpoint. In the case of read, take, readifexists and takeifexists the 19

20 transaction will be placed in the ResponseQueue if a match has been succesfully found or the operation has timed out, returning the resulting tuple to the client. If a match has not been found, this transaction is placed in the ListenerQueue which is implemented to allow for these transactions to be able to find matching tuples until they timeout. In the case of a write transaction, after it is performed it will always be placed in the ListenerQueue as there is no response to be returned to the client. This informs the mechanism in the ListenerQueue that a new tuple has been added which triggers transactions to attempt to check the tuple space for a match. The Transaction class is broken down into two different subclasses: WriteTransaction and FindMatchTransaction. This design allows for flexibility in the type of database interactions being performed. In the context of this project, matching is done based on exact field values but this design may allow for different types of matching like matching with regular expressions. By creating a subclass of Transaction, any type of operation can be performed after creating a specific implementation of the perform() method that is invoked when interacting with the tuple space. Figure 4: The Transaction class and its subclass implementations in this project 20

21 Missing from figure 4 are the details of the SpaceEntry class and the Response class which are used as fields of the Transaction class. SpaceEntry is a class representing the de-serialized JSON received by the RESTful endpoint and contains information necessary for performing the required database operations for the provided tuple. The Response class will contain the tuple result when the operation is complete and will be posted as a JSON string to the appropriate client's RESTful endpoint. FindMatchTransaction is the class that is created for read, take, readifexists and takeifexists operations. They each perform the same operation on the database, finding a tuple match based on matching requirements, and only differ in how the results are handled. By setting the boolean field removeresult, we can indicate when accessing the space whether a successful match should be removed or not, allowing us to indicate a take or a read. The non-blocking readifexists and takeifexists differ from their blocking counter-parts by having a timeout of 0, which is set when posted from the client. This allows for theses transaction to be performed and have the result returned immediately. WriteTransactions are created for write operations and contain an implementation for perform() that simply adds the tuple and its required information to the database. After a WriteTransaction is performed by the TransactionWorker, it is placed immediately in the ListenerQueue. The ListenerQueue will trigger waiting transactions to be performed if the WriteTransaction is of the same class or subclass The ListenerQueue The ListenerQueue, unlike the other queues, contains a static ConcurrentHashMap which maps tuple class names to ListenerForClass objects. The ListenerForClass object contains a barrier which will be shared with a set of ListenerWorkers that are listening for a tuple of a particular class to be added. When new tuples are written to the space, they will notify the ListenerForClass for their class 21

22 name and also their super class allowing responsive transactions to return an object that is the same class or subclass of the template that was provided. The ListenerForClass will arrive at the barrier allowing all ListenerWorkers for that class to continue, where they will attempt to find a matching tuple. When a new responsive transaction is created, it creates or is added to the appropriate ListenerForClass and a ListenerWorker for that particular transaction is launched. When a tuple is added to the space, it checks the hash map for its class name and super class name and notifies their listeners. This allows all ListenerWorkers waiting for that particular class to be released from their lock to perform another check against the tuple space for a match. This is achieved using a Phaser, a locking mechanism part of java.util.concurrent. A Phaser is a more powerful and flexible version of a CyclicalBarrier that allows threads to register and deregister themselves on the fly. It also allows for threads to call await() on the Phaser with a timeout, so a result can be returned at the timeout specified by the client who invoked the call on the space. The ListenerWorker thread. public void run() { //don't perform transaction if the client is terminated while(listening && clientactive()){ boolean foundmatch = transaction.perform(); //send found tuple back to client if(foundmatch transaction.isexpired()){ addtoresponsequeue(); //wait for new write to occur else{ try { int currentphase = phaserlock.arrive(); phaserlock.awaitadvanceinterruptibly(currentphase, transaction.getmillistotimeout(), TimeUnit.MILLISECONDS); catch (InterruptedException TimeoutException e) { //add to response queue on timeoutexception addtoresponsequeue(); catch(illegalstateexception e){ System.out.println(" phase: " + this.phaserlock.getphase() + ", parties : " + this.phaserlock.getarrivedparties()); 22

23 deregisterfromlock(); Above is the loop performed by the ListenerWorker. It first performs the transaction and checks if a match was found. If there is no result it waits for a new tuple by arriving at the Phaser. From here the loop will execute again if a tuple triggers the Phaser to release the arrived parties. If the transaction expires or a match is found, it will be deregistered from the Phaser and the tuple result will be returned to the client MongoDB When transactions are performed they interact with the shared tuple space repository. The tuple repository is stored in a database which is queried by Transactions created in the sever. The database chosen for this project is MongoDB. MongoDB is a NoSQL document database, which stores JSON documents. It was chosen because of its suitability for this project which requires storage of JSON serialized objects. It also provides a built-in solution to a few problems presented in this project. It allows for querying directly against JSON structures allowing for tuples to be stored as is when they are posted to the RESTful web services. This eliminates the need for deconstructing and rebuilding of tuples into tables and columns as would be required in an SQL database. Time out values for tuples is also made simpler using syntax provided by MongoDB allowing a time of expiry to be specified when storing new JSON documents. MongoDB will then automatically check the collection for expired documents and remove them. MongoDB also provides easy syntax for building queries to find matching tuples based on fields that match the template and wild card fields. A MongoDB database is broken down by collection, which can be implemented so that each collection stores a particular type of document. For this project, the server needs to maintain a list of 23

24 tuples in the space as well as a list of active clients. These are represented in the database named TupleSpace by the collections TupleEntries and Clients respectively. Documents in the TupleEntries collection, which represents a particular tuple that has been written to the space, are JSON documents of the form : { _id : MongoDB generated ID (ObjectID), tupleentry : JSON Serialization of Tuple Object (String), tupleexpireat : UTC Date Of Tuple Expiry (Date), clientexpireat : UTC Date Of Client Expiry (Date), clientid : Foreign Client ID (ObjectID), classname : Object Class Name (String), superclassname : Object Super Class Name (String) When a particular tuple entry is written to the space, these fields are set to allow for proper matching and expiry times and are placed in the collection. Transactions which are searching for matches will query the collection to find an tuple of the same class or subclass of the template object which has matching fields and which does not have either expiry date that is less then the current time. The expiry date tupleexpiresat is a date representing the time in milliseconds that the tuple was set to expire at when written to the space. The expiry date clientexpireat is a date that is renewed by clients so that after a client is terminated, the tuples it has written to the space are no longer valid. By setting the query for a particular tuple to find a document where the current date is less then the date in either of these fields, we are ignoring any tuples in the space which have expired. Further, by setting a flag for these fields which enables MongoDB to automatically remove expired documents with a built in document expiry system, maintaining the integrity of the database as it does not contain irrelevant 24

25 data for long. MongoDB performs a check to automatically remove expired documents every 60 seconds, so documents may remain in the database after they expire until this check is performed. For this reason it is necessary for the query to include a check for document expiry. The clientid field contains a foreign key in the Clients collection of the client which placed the tuple in the space. This allows for the clientexpireat field to be updated for every tuple containing the clientid when it's expiry is renewed. When a Client first initializes, it sends information to the RESTful endpoint on the server containing its URL for returning tuples. This along with an expiry is placed in the Clients collection which takes the form of : { _id : MongoDB generated ID (ObjectID), clienturl : Client URL (String), clientexpireat : UTC Date Of Expiry (Date) The string in the field _id which is a unique id automatically generated by MongoDB for each document added, is returned to the client. This ID is then used by the client to identify its transactions and tuples. The client is then required to poll the server at a particular frequency in order to update the expiry date for its representation in the Clients collection, as well as all of the expiry dates for any tuple it has place in the space represented in the TupleEntries collection. When a transaction completes and its result is to be sent back to the client, it uses the client ID associated with it to find the client URL. If that client ID is expired in the Clients collection, then the client has not renewed itself and has been terminated. If the client ID associated with that transaction is expired in the Clients collection, the transaction will terminate and a result will not be sent back. This also allows for tuples written to the space by that client to be expired as well as tuples will have been expired and other transactions will not return them as a successful match. 25

26 4 Conclusion By implementing the various mechanisms and components described in this paper, RSpace is not only a fully functional implementation of a tuple space but is language-independent, lightweight and flexible compared to current implementations of a tuple space. The RSpace project can be a very useful tool for communication in a distributed system. It can be used to add the flexibility and simplicity that comes with the use of a tuple space and can also be used to communicate between applications using different programming languages or applications hosted on different devices. Future work for the RSpace project could include adding the notify operation that is part of JavaSpaces. Notify is a blocking operation used to create a listener for certain types of tuples. It operates similarly to the other operations provided by RSpace in that the user supplies a template and a timeout for the server to find matching tuples but also accepts a RemoteEventListener. Each time a tuple is added to the space that matches the template, the RemoteEventListener that is provided is invoked on the client. The RemoteEventListener to be implemented to perform a certain task for a certain tuple or set of tuples for the length of the timeout provided. This would require an implementation of a mechanism on the server that would work similarly to the other operations but would also repeatedly send responses to the client and ensure that any particular tuple that is a match to the template only invokes the client's RemoteEventListener once. Another area that could be expanded in the RSpace project is implementing other methods of tuple matching such as the use of regular expressions. The design of the project allows for other implementations of transactions like this to be added easily. This project has been a useful learning experience as it has provided many interesting problems that have requiring programming and problem solving skills to solve. It is implemented using design strategies and solutions acquired though course and career work. This project allowed for me to apply 26

27 these tools and skills to create a useful product. I have also gained skills in developing a project using RESTful web services and in other technologies required such as Tomcat and Jersey. 27

28 5 - References 1. David Gelernter. Generative communication in Linda. ACM Transactions on Programming Languages and Systems, January George C. Wells. A Tuple Space Web Service for Distributed Programming. CSREA Press, June Web Services Architecture Working Group. (2004, February 11). Web Services Glossary. Retrieved April 6, 2014, from 4 Bray, T. (2004, October 28). WS-Pagecount. ongoing by Tim Bray. Retrieved April 6, 2014, from 28

29 Appendix A - Testing Test Case 1 : Description Test basic functionality of read Input Expected Results Output Conclusion - create object to write to tuple space - write object to tuple space - read using same object created for write as template Exact copy of object written to space. Same as expected results. read returns copy of desired tuple as expected Test Case 2 : Description Test basic functionality of take Input Expected Results Output Conclusion - create object to write to tuple space - write object to tuple space - take using same object created for write as template - read using same object created for write as template take will return copy of object written to space. read will return null because the take operation has removed tuple from space Same as expected results take returns desired tuple and removes it from the space as expected Test Case 3 : Description Test basic functionality of readifexists Input Expected Results Output Conclusion - create object to write to tuple space - perform first readifexists using created object as template - write object to tuple space - perform second readifexists using created object as template First readifexists will immediately return null because matching tuple is not yet in space. Second readifexists will immediately return a copy of the object written to space since it is invoked after object is put in space. Same as expected results readifexists immediately returns a matching tuple or null if no match is found. 29

30 Test Case 4 : Description Input Expected Results Output Conclusion Test basic functionality of takeifexists - create object to write to tuple space - perform first takeifexists using created object as template - write object to tuple space - perform second takeifexists using created object as template - preform a readifexists using created object as template First takeifexists will immediately return null because matching tuple is not yet in space. Second takeifexists will immediately return a the object written to space since it is invoked after object is put in space. readifexists will immediately return null since the object has been removed from the space by the second takeifexists call. Same as expected results takeifexists immediately returns and removes a matching tuple or null if no match is found. Test Case 5 : Description Input Expected Results Output Conclusion Performing a transaction before tuple exists in space returns result after a delay when tuple is written to space - create object to write to tuple space - launch thread to perform read transaction using created object with timeout of 10 seconds - make main thread sleep for 5 seconds - write created object Copy of created object returned after 5 seconds Same as expected If a read transaction does not find a matching tuple when it is invoked, it will return a result in the event that the matching tuple is written after a delay Test Case 6 : Description Input Expected Results Transactions expire after timeout - create object to use a template - invoke read using created object with timeout of 10 seconds - invoke take using created object with timeout of 10 seconds Read will return null after 10 seconds 30

31 Output Conclusion take will return null after 20 seconds Same as expected Read and take will return a result if a match is found, or null if timeout expires before a match is found Test Case 7 : Description Input Expected Results Output Conclusion A tuple written to space expires after timeout - create an object to write to space - perform write using created object with timeout of 10 seconds - pause thread for 10 seconds - perform readifexists using created object as a template with readifexists returns null because tuple has expired from the space Same as expected Tuples will no longer be accessible in the space after they expire Test Case 8 : Description Input Expected Results Output Conclusion Finding match by subclass - create an object called superobject using a default constructor - create an object called subclassobject that is a subclass of superobject using default constructor - write subclassobject to space - read using superclassobject as a template Read will return a tuple from space that is a copy of the subclassobject that was written to the tuple space. Same as expected Both superobject and subclassobject only have wildcards as fields so subclassobject is return as a result because it is a subclass of the template. Test Case 9 : Description Input Matching using subclassing as well as fields - create Object1 that has an integer field intfield set to 99, for example - create Object2, a subclass of Object1 with intfield set to 33 - create Object3, a subclass of Object1 with intfield set to 99 - write Object2 - write Object3 31

32 Expected Results Output Conclusion Test Case 10 : - read using Object1 as a template Read will return a copy of Object3. Same as expected All matching requirements must be met for a tuple to be returned, in this case the resulting tuple must have an equal value in the field set in the template, as well as be of the same class or a subclass of the template. Description Input Expected Results Interaction between two clients accessing tuple space - client1 creates an object called msg1 with string field set to Message from client 1 and an integer field set to 1 - client1 performs write using msg1 - client1 performs take using a template with integer field set to 2 - client2 creates an object called msg2 with string field set to Message from client 2 and an integer field set to 2 - client2 performs write using msg2 - client2 performs take using a template with integer field set to 1 - client1 and client2 each print the string contained in the object retreived from their take Client1 will receive the object written by Client2 and Client2 will receive the object written by Client1 Output Client1 - Message From Client 2 Client2 - Message From Client 1 Conclusion Multiple clients can access the shared space concurrently 32

33 Appendix B : The RESTful interface The server has several RESTful endpoints exposed that can be used to interact with the server by posting the required JSON. By default these endpoints are hosted at Operation Read : Take : Write : Endpoint These operations consume a JSON string in the form : { "tuple": { "name": class name (string), "serializedtuple": JSON serialized tuple (string), "superclass": super class name (string), "expirydate": date and time of expiry for transaction in milliseconds (long), "clientid": server generated Client ID (string) Read and take endpoints respond with an Integer representing the transaction ID. Endpoints are available for registering a client and renewing its expiry date. Operation Register client on initialization Renew client expiry Endpoint

34 These Endpoints consume JSON in the form : { "clientid": client ID (string), "url": url for posting tuple results to client (string), "timeout": date for expiry in milliseconds(long) The registerclient endpoint returns a response containing a String that is the Client ID. These endpoints are located in the RSpace server in the package com.carleton.paulhayman.rswebservice.resources. On the client the endpoints and URL are configured in the class RSpace. Completed transactions on the server will be posted to the client at it's RESTful Endpoint. These are posted to the client as JSON structures in the form: { "transid": transaction ID (int), "clientid": client ID (String), "serializedtuple": JSON serialized tuple result (String), "classname": class name of tuple result, used to deserialize (String) 34

35 Appendix C : Setup Instructions 1) Install and run the latest version of MongoDB. The connection url is set in the class MongoDbImpl on the server by setting the static Strings HOST and PORT. These are set to localhost and which is the default location of the MongoDB database connection. 2) Run the server which is the Java project RSWebService. Install the latest version of Apache Tomcat and run on apache server (There may be build errors until apache installation is referenced). This will be hosted by default at This is the base url the client accesses by default and can be changed in the class RSpace in the client library by changing the String value for BASE_URL. Individual endpoint names are specified in their respective classes on the server, all of which are contained in the com.carleton.paulhayman.rswebservice.resources package. These endpoint names are specified for access in the client in the RSpace class as static strings. 3) Access the server by using the client library which is the Java project RSpace. An instance can be created by using the static function in the class RSpace called getrspace(). When invoked a RESTful endpoint will be created on the client at by default. If multiple instances of RSpace are created on the same machine a different port must be specified so a new endpoint can be created. This can be done by specifying a port when calling the function getrspace(int port). 35