Configuration
The configuration of Testbed Runtime is non-trivial, therefore we provide some scenarios to illustrate the usage of the configuration files. Please feel free to improve, fix or remove outdated documentation!
TODO: Write Me!
TODO: This description needs improvement such as inlined configuration files and explanations of them!
The scenario contains a small-sized testbed in which all wireless sensor nodes are attached to the testbed server that exhibits the testbed to the internet as show below:
For setting up the testbed you'll need several components that, together form a fully functional testbed (according to the specifications of the WISEBED project):
The following image describes the scenario above in more detail, describing the Web Service endpoints and node names involved:
The configuration files for iWSN, SNAA and RS located in doc/quick-start-simple/ reflect the scenario above. After you have installed the testbed-runtime assembly, simply copy the files to the conf/ subdirectory. Then replace the hostnames and URNs with hostnames and URNs that fit your needs and reflect your (domain) infrastructure and you're ready to go.
The iWSN is here configured (cmp. doc/quick-start-simple/tr.iwsn-testbed.xml) to connect with five sensor nodes and to expose itself to web service clients as depicted in the image above. Furthermore the configuration file points to the WiseML file doc/quick-start-simple/tr.iwsn-wiseml.xml that is to be delivered to web service clients asking for the network topology.
For detailed information on configuring and starting the iWSN system please see iWSN.
The SNAA is here configured to use a htpasswd-file for storing authentication credentials. It does so by using the HtpasswdFile module of JAAS which is configured by the file doc/quick-start-simple/tr.snaa-testbed.jaas (parameter configfile in doc/quick-start-simple/tr.snaa-testbed.properties).
The JAAS config file further points to the file doc/quick-start-simple/tr.snaa-testbed.htpasswd which is a regular htpasswd file as also used by Apache HTTPD.
You guessed right, the clear-text password is testbeduzl1.
For detailed information on configuring and starting the SNAA please see SNAA.
The configuration file doc/quick-start-simple/tr.rs-testbed.properties reflects the scenario described above.
The RS is here configured to use an inmemory "persistence" layer (see persistence parameter) as it is the easiest for demonstration purposes.
For detailed information on configuring and starting the reservation system, as well as on other persistence layers such as JPA or Google Calendar, please see the Reservation System.
The scenario contains a testbed in which wireless sensor nodes are attached to gateways and which are themselves attached to a portal server that exhibits the testbed to the internet:
For setting up the testbed you'll need several components that, together form a fully functional testbed (according to the specifications of the WISEBED project):
The iWSN implementation in this scenario starts up a basic overlay network in which nodes are addressed by their URN. Nodes of the overlay network run on both the portal server as well as on the various gateway machines. Every physical node can have multiple names (= node URNs) associated with it. In the example the individual machines all run an overlay node on port 8080. Gateway machines inherit the names of the attached sensor nodes as names in the overlay network. So, in the example Gateway1 can be addressed as both urn:wisebed:testbeduzl1:1 as well as urn:wisebed:testbeduzl1:2 in the overlay network. For now, this should be enough of the "theory", you'll see more in the next section.
The configuration of the various implementations is pretty similar to the configuration in the simple quickstart scenario above. The largest difference you'll find for the iWSN implementation as we now have to configure how the overlay network is built.
The configuration files for iWSN, SNAA and RS located in doc/quick-start-complex/ reflect the scenario above. After you have installed the testbed-runtime assembly, simply copy the files to the conf/ subdirectory. Please note: In contrast to the simple quickstart scenario the assembly must be installed and started on every host with identical configuration files. Before you do this you should replace the hostnames and URNs with hostnames and URNs that fit your needs and reflect your (domain) infrastructure and you're ready to go.
The iWSN is here configured (cmp. doc/quick-start-complex/tr.iwsn-testbed.xml) for each node individually. E.g. the testbed Web Service is run on testbeduzl1.itm.uni-luebeck.de as one can see in the configuration:
<nodes id="testbeduzl1.itm.uni-luebeck.de">
<names>
<nodename name="testbeduzl1.itm.uni-luebeck.de"/>
</names>
<serverconnections>
<serverconnection address="testbeduzl1.itm.uni-luebeck.de:8880" type="tcp"/>
</serverconnections>
<applications>
<application factoryclass="de.uniluebeck.itm.tr.runtime.portalapp.PortalServerFactory" name="Portal">
<ns3:portalapp>
<webservice>
<urnprefix>urn:wisebed:testbeduzl1:</urnprefix>
<sessionmanagementendpointurl>http://testbeduzl1.itm.uni-luebeck.de:8888/sessions</sessionmanagementendpointurl>
<wsninstancebaseurl>http://testbeduzl1.itm.uni-luebeck.de:8888/wsn/</wsninstancebaseurl>
<reservationendpointurl>http://testbeduzl1.itm.uni-luebeck.de:8889/rs</reservationendpointurl>
<wisemlfilename>../conf/tr.iwsn-wiseml.xml</wisemlfilename>
</webservice>
</ns3:portalapp>
</application>
</applications>
</nodes>
The interesting point here now is the <serverconnection> tag that defines the address and port on which to run the aforementioned overlay network that connects the testbed server with the two gateway machines. Also, please note that the configuration in the listing above does not include any sensor nodes to connect to as they will be used in the other hosts of the overlay network. The listing below shows the configuration snippet of the gateway host testbeduzl1-gw1.itm.uni-luebeck.de (the configuration of testbeduzl1-gw2.itm.uni-luebeck.de is analogue):
<nodes id="testbeduzl1-gw1.itm.uni-luebeck.de">
<names>
<nodename name="urn:wisebed:testbeduzl1:0x1"/>
<nodename name="urn:wisebed:testbeduzl1:0x2"/>
</names>
<serverconnections>
<serverconnection address="testbeduzl1-gw1.itm.uni-luebeck.de:8880" type="tcp"/>
</serverconnections>
<applications>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
<ns4:wsnDevice>
<urn>urn:wisebed:testbeduzl1:0x1</urn>
<type>isense</type>
</ns4:wsnDevice>
</application>
<application factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory" name="WSNDeviceApp">
<ns4:wsnDevice>
<urn>urn:wisebed:testbeduzl1:0x2</urn>
<type>isense</type>
</ns4:wsnDevice>
</application>
</applications>
</nodes>
As you can see, the node (of the overlay network) can be addressed by two names (urn:wisebed:testbeduzl1:0x1, urn:wisebed:testbeduzl1:0x2) that are identical to the URNs of the sensor nodes. The WSNDeviceApp application that is configured here too is responsible for connecting to the sensor node and to listen for every message in the overlay network that sends messages to the corresponding URN. The serial port of the sensor node is automatically detected. Please note: at the time of writing this feature only works for iSense, Telos B and Pacemate nodes and only on Linux. For detecting the serial port of a Telos B node there needs to be additional configuration. For more details please see this mailing list message.
Please note that also here a <serverconnection> tag configures how the overlay network is constructed.
Furthermore the configuration file points to the WiseML file doc/quick-start-complex/tr.iwsn-wiseml.xml that is to be delivered to web service clients asking for the network topology.
For detailed information on configuring and starting the iWSN system please see iWSN.
The SNAA is here configured to use a htpasswd-file for storing authentication credentials. It does so by using the HtpasswdFile module of JAAS which is configured by the file doc/quick-start-complex/tr.snaa-testbed.jaas (parameter configfile in doc/quick-start-complex/tr.snaa-testbed.properties).
The JAAS config file further points to the file doc/quick-start-complex/tr.snaa-testbed.htpasswd which is a regular htpasswd file as also used by Apache HTTPD.
You guessed right, the clear-text password is testbeduzl1.
For detailed information on configuring and starting the SNAA please see SNAA.
The configuration file doc/quick-start-complex/tr.rs-testbed.properties reflects the scenario described above.
The RS is here configured to use an inmemory "persistence" layer (see persistence parameter) as it is the easiest for demonstration purposes.
For detailed information on configuring and starting the reservation system, as well as on other persistence layers such as JPA or Google Calendar, please see Reservation System using a Google Calendar.
TODO: Write Me!