This article describes how JAX-WS RI 2.0 can be used to generate asynchronous Web service clients. This could help to reduce the number of threads that are necessary for client message delivery.

Here is another article on this topic.

Think of a clever way to enable an experiment that is run when there are no reservations without flashing the nodes too often.

The module could, e.g. be started as an extra app that listens to events emitted by WSNServiceImpl and is able to use his own WSNApp instance to flash nodes and receive outputs.

Do XML streaming validation of WiseML using a piped in/out-stream.

Using Binding Customization we can use the DatatypeConverter mechanism to make the imported classes more comfortable for usage. E.g. adding dates as XMLGregorianCalender is highly unpleasant so it would be nice to have a converter that converts java.util.Date or org.joda.DateTime objects to XMLGregorianCalendar.

Put the WISEBED API documentation into the .xjb files that are used for generating the service and type binding classes so that we have a nice JavaDoc based documentation of the WISEBED APIs.

In 0.7 release I forgot to add a federator assembly consisting of iWSN, RS and SNAA federators.

• don't create so many tmp files or delete them after execution
• only do one motelist per program startup

The SDK must support both synchronous and asynchronous method invocation and should be fully documented using JavaDoc, including WISEBED APIs documentation.

The Remote-UART protocol must be integrated into the backend as an optionally configurable component. Enabling the RUP-option will result in every communication from and to the node to be wrapped in a RUP packet.

The use case is that for a non-wired testbed all packets that are sent to a nodes' UART (e.g. via WSNService.send()) will be transparently forwarded to the unwired node if all or a subset of the nodes in the sensor network talk the RUP protocol. One implementation of the RU protocol is to be found within the WISELIB.

As DeviceObserver can be used in many projects move it to the wsn-device-utils project.

I'd suggest to modify StringUtils toHexString methods to give some control on how HexStrings are created.

Right now, a toHexString called over [00:13:A2:00:40:6D:0B:5A] results in "0x0 0x13 0xa2 0x0 0x40 0x6d 0xb 0x5a". Each hex byte should be always 2 digits, and some parameters could be passed to avoid '0x' and to change ' ' as separator.

Only occurs in combination with the usage of JPA:

java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:114)
    at java.util.jar.JarFile.<init>(JarFile.java:135)
    at java.util.jar.JarFile.<init>(JarFile.java:72)
    at org.hibernate.ejb.packaging.FileZippedJarVisitor.doProcessElements(FileZippedJarVisitor.java:34)
    at org.hibernate.ejb.packaging.JarVisitor.getMatchingEntries(JarVisitor.java:229)
    at org.hibernate.ejb.Ejb3Configuration.addMetadataFromVisitor(Ejb3Configuration.java:258)
    at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:234)
    at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:120)
    at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
    at de.uniluebeck.itm.tr.rs.persistence.jpa.impl.RSPersistenceJPAImpl.<init>(RSPersistenceJPAImpl.java:54)
    at de.uniluebeck.itm.tr.rs.persistence.jpa.RSPersistenceJPAFactory.createInstance(RSPersistenceJPAFactory.java:40)
    at de.uniluebeck.itm.tr.rs.cmdline.Main.createPersistenceDB(Main.java:243)
    at de.uniluebeck.itm.tr.rs.cmdline.Main.createRSPersistence(Main.java:175)
    at de.uniluebeck.itm.tr.rs.cmdline.Main.startSingleUrnPrefixRS(Main.java:153)
    at de.uniluebeck.itm.tr.rs.cmdline.Main.setProperties(Main.java:120)
    at de.uniluebeck.itm.tr.rs.cmdline.Main.main(Main.java:92)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at com.simontuffs.onejar.Boot.run(Boot.java:329)
    at com.simontuffs.onejar.Boot.main(Boot.java:164)

Happended through integration of wsn-device-drivers project.

This topic is already in work

Upon invocation of SessionManagement.areNodesAlive a NullPointerException is thrown.

Request:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:ct="urn:CommonTypes" 
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:tns="urn:SessionManagementService">
    <soap:Body>
        <tns:areNodesAlive>
            <nodes>urn:wisebed:uzl1:0x012c</nodes>
            ...
            <nodes>urn:wisebed:uzl1:0xfee3</nodes>
            <nodes>urn:wisebed:uzl1:210</nodes>
            ...
            <nodes>urn:wisebed:uzl1:642</nodes>
            <controllerEndpointUrl>http://141.83.68.35:8089</controllerEndpointUrl>
        </tns:areNodesAlive>
    </soap:Body>
</soap:Envelope>

Response:

<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
    <S:Body>
        <S:Fault xmlns:ns4="http://www.w3.org/2003/05/soap-envelope">
            <faultcode>S:Server</faultcode>
            <faultstring>java.lang.NullPointerException</faultstring>
            <detail>
                <ns2:exception xmlns:ns2="http://jax-ws.dev.java.net/" class="java.lang.NullPointerException"
                    note="To disable this feature, set com.sun.xml.ws.fault.SOAPFaultBuilder.disableCaptureStackTrace system property to false">
                    <ns2:stackTrace>
                        <ns2:frame class="eu.wisebed.testbed.api.wsn.deliverymanager.DeliveryManager" file="DeliveryManager.java"
                            line="133" method="addController" />
                        <ns2:frame class="de.uniluebeck.itm.tr.runtime.portalapp.SessionManagementServiceImpl" file="SessionManagementServiceImpl.java"
                            line="460" method="areNodesAlive" />
                        <ns2:frame class="sun.reflect.GeneratedMethodAccessor72" line="unknown" method="invoke" />
                        <ns2:frame class="sun.reflect.DelegatingMethodAccessorImpl" file="DelegatingMethodAccessorImpl.java"
                            line="25" method="invoke" />
                        <ns2:frame class="java.lang.reflect.Method" file="Method.java" line="597" method="invoke" />
                        <ns2:frame class="com.sun.xml.ws.api.server.InstanceResolver$1" file="InstanceResolver.java" line="246"
                            method="invoke" />
                        <ns2:frame class="com.sun.xml.ws.server.InvokerTube$2" file="InvokerTube.java" line="146" method="invoke" />
                        <ns2:frame class="com.sun.xml.ws.server.sei.EndpointMethodHandler" file="EndpointMethodHandler.java"
                            line="257" method="invoke" />
                        <ns2:frame class="com.sun.xml.ws.server.sei.SEIInvokerTube" file="SEIInvokerTube.java" line="95"
                            method="processRequest" />
                        <ns2:frame class="com.sun.xml.ws.api.pipe.Fiber" file="Fiber.java" line="629" method="__doRun" />
                        <ns2:frame class="com.sun.xml.ws.api.pipe.Fiber" file="Fiber.java" line="588" method="_doRun" />
                        <ns2:frame class="com.sun.xml.ws.api.pipe.Fiber" file="Fiber.java" line="573" method="doRun" />
                        <ns2:frame class="com.sun.xml.ws.api.pipe.Fiber" file="Fiber.java" line="470" method="runSync" />
                        <ns2:frame class="com.sun.xml.ws.server.WSEndpointImpl$2" file="WSEndpointImpl.java" line="295" method="process" />
                        <ns2:frame class="com.sun.xml.ws.transport.http.HttpAdapter$HttpToolkit" file="HttpAdapter.java" line="519"
                            method="handle" />
                        <ns2:frame class="com.sun.xml.ws.transport.http.HttpAdapter" file="HttpAdapter.java" line="288" method="handle" />
                        <ns2:frame class="com.sun.xml.ws.transport.http.server.WSHttpHandler" file="WSHttpHandler.java" line="106"
                            method="handleExchange" />
                        <ns2:frame class="com.sun.xml.ws.transport.http.server.WSHttpHandler" file="WSHttpHandler.java" line="91"
                            method="handle" />
                        <ns2:frame class="com.sun.net.httpserver.Filter$Chain" file="Filter.java" line="65" method="doFilter" />
                        <ns2:frame class="sun.net.httpserver.AuthFilter" file="AuthFilter.java" line="65" method="doFilter" />
                        <ns2:frame class="com.sun.net.httpserver.Filter$Chain" file="Filter.java" line="68" method="doFilter" />
                        <ns2:frame class="sun.net.httpserver.ServerImpl$Exchange$LinkHandler" file="ServerImpl.java" line="555"
                            method="handle" />
                        <ns2:frame class="com.sun.net.httpserver.Filter$Chain" file="Filter.java" line="65" method="doFilter" />
                        <ns2:frame class="sun.net.httpserver.ServerImpl$Exchange" file="ServerImpl.java" line="527" method="run" />
                        <ns2:frame class="java.util.concurrent.ThreadPoolExecutor$Worker" file="ThreadPoolExecutor.java" line="886"
                            method="runTask" />
                        <ns2:frame class="java.util.concurrent.ThreadPoolExecutor$Worker" file="ThreadPoolExecutor.java" line="908"
                            method="run" />
                        <ns2:frame class="java.lang.Thread" file="Thread.java" line="619" method="run" />
                    </ns2:stackTrace>
                </ns2:exception>
            </detail>
        </S:Fault>
    </S:Body>
</S:Envelope>

Since the backend uses only one TCP connection to the client since fixing trac #142 the overall performance of message delivery decreased strongly. This is because there's no multiplexing of multiple calls on that TCP connection, so every call takes one Web Service roundtrip of time.

To temporarily overcome this issue one can either set the environment variable http.keepAlive=false to not reuse TCP connection. This however would result in trac #142 occuring again.

The clean way to solve this would be a change in the APIs, allowing to deliver more than one sensor node message at a time.

Drivers are integrated in new-drivers branch but must still be tested on new staging testbed for the current device platforms.

As the motap modules are still used but not really part of the TR project move them out to a small special purpose project.

Obviously, the quick fix didn't work out yet so we have to test more deeply...

Create a WiseML "player" that can set/unset real/virtual links on the testbed using calls to setVirtualLink/destroyVirtualLink and enablePhysicalLink/disablePhysicalLink of the iWSN API.

The WiseML player should skip through a WiseML file and always search the next entry when a link status is to be changed. This is indicated using the following WiseML tags:

<enableLink source="..." target="..." />
<disableLink source="..." target="..." />

More information about WiseML is found here.

WiseML just defines when links should be set or unset. It is unclear, however, if this is a real or a virtual link to be created. The player needs a way of mapping the XML Tags to calls to setVirtualLink/destroyVirtualLink or enablePhysicalLink/disablePhysicalLink respectively.

A possible way would be to use the WiseML description returned by getNetwork if the information is present.

The player should be capable of using other types of backends (i.e., not just a WISEBED backend). This should be done by defining an interface where setVirtualLink/destroyVirtualLink and enablePhysicalLink/disablePhysicalLink is defined.

One implementation would be to issue calls to a iWSN backend, another implementation would be done by the University of Bonn and would directly issue commands to a serial interface.

Design a module that listens to connected and disconnected events of the DeviceObserver module and starts and stops WSNDeviceApp accordingly to create a plug-and-pray behaviour of Testbed Runtime.

This feature will not allow the addition or removal of nodes out of the testbed at runtime, but will reconnect to nodes that are temporarily removed and reattached during runtime.

There should be just one dependency for clients to include in order to communicate with WISEBED testbeds. Therefore merge the three modules wsn-api, rs-api and snaa-api into one.

Currently, the unit tests of the RS persistence layer start up a full blown SNAA and RS service and run tests against the Web services. This should be changed to only test the actual implementation logic, thereby not including the Web service stack and fasten up the testing and thereby the build process.

It is nice that we have a test for the GCal persistence. However, it sometimes fails which is very annoying, e.g. during a release which takes long. We could leave the test but take it out of the default build.

Design a library DeviceObserver that observes nodes attached to and detached from the USB hub and fires events on changes. After a device is attached try to connect and read out meta data such as device type, device port, reference ID (for Telos B) and MAC address. Attach this meta data as a set of key-value pairs (Map) to the connected or disconnected event.

The actual detection logic is run as OS-specific scripts (such as in motelist today) and is executed periodically. Execution happens using an Executor that is passed into the DeviceObserver library on instance creation. Events are fired using the Executor asynchronously. Make sure that, if connecting to the device is necessary to read meta data, the connection is closed before firing the event.

Interfaces and the CSV format and its supported values must be documented.

Base the implementation on the new 'rsc' drivers.

When trying to flash more than 5 devices all are detected but only 5 of them participate in flashing MOTAP flash proccess.

Output:

JarClassLoader: Warning: Null manifest from input stream associated with: lib/netty-3.2.3.Final.jar
JarClassLoader: Warning: Null manifest from input stream associated with: lib/jtidy-4aug2000r7-dev.jar
2011-05-19 13:12:09,605 | main | WisebedMotapCLI | DEBUG | Successfully started HTTP server for local controller endpoint at port 52021
2011-05-19 13:12:10,053 | main | WisebedMotapConnectorImpl | INFO | Bound local controller endpoint to http://gold:52021/A1C6040599F068F94BFA951EFCECA36D.
2011-05-19 13:12:10,078 | main | WisebedMotapConnectorImpl | INFO | Connected to testbed node urn:wisebed:ctitestbed:0x6699.
2011-05-19 13:12:10,184 | main | OtapPlugin | WARN | The new Program does not support OTAP functionality! 2
2011-05-19 13:12:10,196 | main | OtapPlugin | INFO | OTAP::Started PresenceDetect.
2011-05-19 13:12:10,213 | Controller-Thread 0 | SerAerialPacket | WARN | Packet[2]: Advertised payload lenght: 110, Complete packet size is 15, max payload len: 6
2011-05-19 13:12:11,208 | main | MotapController | INFO | found the following 6 devices: [1b70, 1b71, 1b85, 1ccd, 1ccd, ddba]
2011-05-19 13:12:11,208 | main | MotapController | INFO | found all devices
2011-05-19 13:12:11,209 | main | MotapController | INFO | found the following 6 devices: [1b70, 1b71, 1b85, 1ccd, 1ccd, ddba]
2011-05-19 13:12:11,210 | main | OtapPlugin | INFO | OTAP::Stopped PresenceDetect.
2011-05-19 13:12:11,211 | main | MotapController | INFO | start programming
2011-05-19 13:12:11,212 | main | OtapPlugin | INFO | Loading OTAP file: iSenseCollectorApp.bin
2011-05-19 13:12:11,239 | main | BinProgram | INFO | OTAP::Done, got 21 chunks.
2011-05-19 13:12:11,281 | main | BinProgram | INFO | OTAP::Loaded OTAP bin file: iSenseCollectorApp.bin Chip type: JN513XR1 OtapFunctionality of loaded program: Otap
2011-05-19 13:12:11,281 | main | OtapPlugin | INFO | Started OTAP Init phase.
2011-05-19 13:12:11,281 | main | OtapInit | INFO | Starting participating devices run, 5 should participate
2011-05-19 13:12:11,281 | main | OtapPlugin | INFO | flash progress for device 0x1b85: 0
2011-05-19 13:12:11,282 | main | OtapPlugin | INFO | flash progress for device 0x1b70: 0
2011-05-19 13:12:11,282 | main | OtapPlugin | INFO | flash progress for device 0x1ccd: 0
2011-05-19 13:12:11,282 | main | OtapPlugin | INFO | flash progress for device 0x1b71: 0
2011-05-19 13:12:11,282 | main | OtapPlugin | INFO | flash progress for device 0xddba: 0
2011-05-19 13:12:13,872 | Controller-Thread 0 | OtapPlugin | INFO | flash progress for device 0x1b85: 0
2011-05-19 13:12:14,012 | Controller-Thread 0 | OtapPlugin | INFO | flash progress for device 0x1b71: 0
2011-05-19 13:12:14,204 | Controller-Thread 0 | OtapPlugin | INFO | flash progress for device 0x1b70: 0
2011-05-19 13:12:14,756 | Controller-Thread 0 | OtapPlugin | INFO | flash progress for device 0xddba: 0
2011-05-19 13:12:14,960 | Controller-Thread 0 | OtapPlugin | INFO | flash progress for device 0x1ccd: 0