- Decision Boards
- Research Clusters
- Joint Seminars
- Testbed & Simulation
- Summer School
- Visitor Programme
- In the News
- News Archive
Two COOJA plugins and manuals have been published to integrate the TWIST testbed in COOJA and to take checkpoints and perform rollbacks both in TWIST and COOJA.
The 4th International Workshop on Networks of Cooperating Objects for Smart Cities 2013 (CONET/UBICITEC 2013), colocated with CPSWeek 2013, accepts submissions until January 28th, 2013.
The 19th CONET newsletter has been published. You can read on Virtual Organizations for Multi-Model Based Embedded Systems and on the UvA Bird Tracking System.
In this phase of the task, the work is concentrated on prototyping and refining the two core interfaces of the CONET testbed federation platform: Testbed Adaptation API (TA API) as common abstraction over the existing capabilities of the participating testbeds; and a Testbed Federation API (TF API) that leverages the services of the individual testbeds, exported through the TA API, to build a higher level abstraction over the federation aggregate.
- The complete code for the CONET testbed federation prototype is released as open source and available at the public repository http://cotefe.googlecode.com
- The front-end for the CONET Testbed Federation prototype is reachable at http://www.cotefe.net
Testbed Adaptation API
The prototyping of the TA API is performed on top of TWIST due to its mature remote access architecture and large popularity in the WSN community. To facilitate easy porting of the TA API prototype on other testbeds, the prototype has been further decomposed in two parts: a generic web server implemented in Python using the Django web framework, and a thin TWIST-specific wrapper that interfaces with the native TWIST API. The two parts of the TA API prototype currently interact using a generic XML-RPC bridge.
- The TA API prototype sever (for the TWIST testbed) is reachable at: https://www.twist.tu-berlin.de:8001
Testbed Adaptation Prototype for TWIST
The following table describes the mapping between the common testbed operations exposed in the Testbed Adaptation API and their implementation in the native TWIST API, via the XML-RPC bridge.
|Description||Content-Type||TAA Req Methods||TAA Req URI||XML-RPC API (twist_xmlprc_api.py)||TWIST (user.py)|
|how to get the information about the testbed||application/json||GET||/|
|how to get a list of all images||application/json||GET||/images/|
|how to upload (not burn) a new image||application/x-www-form-urlencoded||POST||/images/|
|how to get the representation of a given image||application/json||GET||/images/ID|
|how to edit information about a given image||application/json||PUT||/images/ID|
|how to delete a given image||-||DELETE||/images/ID|
|how to get a list of all reserved jobs by all users||application/json||GET||/jobs/||xmlrpc_getAllJobs()||getAllJobs()|
|how to create a new job||application/json||POST||/jobs/||xmlrpc_createJob()||addSingleJob()|
|how to get the representation of a given job||application/json||GET||/jobs/ID||xmlrpc_getJobById()||getSingleJob()|
|how to edit information about a given job||application/json||PUT||/jobs/ID||xmlrpc_updateJobById()||updateSingleJob()|
|how to cancel the reservation of a given job||-||DELETE||/jobs/ID||xmlrpc_deleteJobById()||deleteListJobs()|
|how to get the list of logs related to a given job||application/json||GET||/jobs/ID/logs/|
|how to get the representation of a log||application/json||GET||/jobs/ID/logs/ID|
|how to delete a given log (TBC)||-||DELETE||/jobs/ID/logs/ID|
|how to get the list of traces related to a given job||application/json||GET||/jobs/ID/traces/|
|how to get a given trace related to a given job||application/json||GET||/jobs/ID/traces/ID|
|how to delete a given trace (TBC)||-||DELETE||/jobs/ID/traces/ID|
|how to get the list of nodesgroups involved in the job||application/json||GET||/nodegroups/|
|how to create a new nodegroup||application/json||POST||/nodegroups/|
|how to get information about a given nodegroup||application/json||GET||/nodegroups/ID|
|hot to update information about a nodegroup||application/json||PUT||/nodegroups/ID|
|how to delete a nodegroup||-||DELETE||/nodegroups/ID|
|how to install an image on a given nodegroup||application/json||PUT||/nodegroups/ID/image/ID||xmlrpc_burnImageToNodeList()||executeOldBurnAction|
|how to erase an image from a nodegroup"||-||DELETE||/nodegroups/ID/image/ID||xmlrpc_burnImageToNodeList()||executeOldBurnAction|
|how to get the list of nodes for a given nodegroup||application/json||GET||/nodegroups/ID/nodes/|
|how to check whether a node is part of a nodegroup||application/json||GET||/nodegroups/ID/nodes/ID|
|how to add a node to a given nodegroup||-||PUT||/nodegroups/ID/nodes/ID|
|how to delete a node from a given nodegroup||-||DELETE||/nodegroups/ID/nodes/ID|
|how to get all nodes of the testbed||application/json||GET||/nodes/||xmlrpc_getAllNodes()||getAllNodes() - getAllBindedNodes()|
|how to get the representation of a given node||application/json||GET||/nodes/ID||xmlrpc_getNodeById()||getNodeById()|
|how to install an image on a given node||-||PUT||/nodes/ID/image/ID||xmlrpc_burnImageToNodeList()||executeOldBurnAction|
|how to erase an image from a node"||-||DELETE||/nodes/ID/image/ID||xmlrpc_burnImageToNodeList()||executeOldBurnAction|
|how to get the list of all platforms supported by a testbed||application/json||GET||/platforms/||xmlrpc_getAllPlatforms()||getAllPlatforms()|
|how to get information about a give platform||application/json||GET||/platforms/ID||xmlrpc_getPlatformById()||getPlatformById()|
|how to get the list of the users||application/json||GET||/users/|||
|how to get the representation of a given user||application/json||GET||/users/ID|
Testbed Federation API
In parallel, we have continued with the prototyping of the CONET Testbed Federation Server (CTFS) and its TF API on top of the Google App Engine (GAE) platform. Using the Django-Nonrel framework, the prototype implementation hides the complexity of the native GAE data store behind a convenient SQL-like API that increases the portability of the implementation and allows more easy migration to alternative cloud service providers.
The existing frontend server and TF API prototype support the concept of federated authentication using the OpenID protocol. Further development of the common authentication support is postponed for Y4, pending a final adoption of the new OAuth 2.0 standard that matches our requirements much better than the OAuth 1.0 version, leveraged in the original design of the CTF architecture.