On National Teacher Day, meet the 2024-25 Kenan Fellows
Design & Implementation Issues in a Contemporary Remote Laboratory Architecture
1. Design & Implementation Issues in a
Contemporary Remote Laboratory
Architecture
Mark Schulz, CEIT
&
Adam Rudd, School of ITEE & CEIT
The University of Queensland
REV2011 Conference, Brasov, Romania
2. Why undertake this
project?
Enhance the user experience
Produce open source code
REV2011 Conference, Brasov, Romania
3. Format of Talk
Review of iLab Architecture
Indicate some limitations
Propose some desirable enhancements
Look at some possible implementation
issues
Very short demonstration
REV2011 Conference, Brasov, Romania
4. Review of iLab
Architecture
Ser vice Oriented Architecture based on
Web Services
Three major components
Ser vice Broker - Authentication &
Authorisation, delivery of client
LabSer ver - runs the experiment
Client - send, receives and displays data
REV2011 Conference, Brasov, Romania
5. Limitations of iLab
Architecture
SERVICE BROKER:
Authentication & Authorisation are not
a ser vice
Client is launched from the SB.
REV2011 Conference, Brasov, Romania
9. Limitations of iLab
Architecture
Development tool chain is (currently)
Microsoft centric
fragile tool chain
shortage of student C# developers at our
institution
Uses a non-standard Microsoft SQL
database
REV2011 Conference, Brasov, Romania
10. Limitations of iLab
Architecture
No built-in support for real-time
messaging.
Some functions generate excessive
activity, e.g., to build an experiment
progress bar.
Others not possible,e.g., to build a real-
time job queue viewer
REV2011 Conference, Brasov, Romania
11. Limitations of iLab
Architecture
No architecture support for distributed
collaboration around the client.
Current model is collaboration around a
single remote client - requires physical
presence.
This is NOT about chat sessions and
shared whiteboards, although these would
form part of this approach.
REV2011 Conference, Brasov, Romania
12. Desirable Enhancements
to iLab Architecture
‘Rig-as-a-Service’
Client interfaces can be anywhere
User needs an account on a trusted
ser vice broker to execute the rig, book a
session, etc.
Moves operation from Service Broker
centric to Lab Server centric.
REV2011 Conference, Brasov, Romania
13. Desirable Enhancements
to iLab Architecture
Real-time, one-to-many messaging
Operational Data - progress bar
Experiment Data - interactive
experiments, sensor experiments
Client operational data - button pressed
is pushed to all collaborating clients
REV2011 Conference, Brasov, Romania
14. Implementation Issues
RESTful interface to replace SOAP
Far simpler and more powerful
More developers familiar with this now.
NOTE: RESTful does not support real-time.
No standard for real-time messaging
here.
REV2011 Conference, Brasov, Romania
15. Implementation Issues
A previous talk today looked at the design
of the client in HTML 5, CSS, and
JavaScript.
Why not reduce the number of languages
involved and go for server-side Javascipt
(node.js)
JS is event-driven cf. SOAP which is RPC.
REV2011 Conference, Brasov, Romania
17. Implementation Issues
If we make the break with SOAP and
move to JavaScript, should we follow the
trend of other web developers and move
totally from XML to JSON?
REV2011 Conference, Brasov, Romania
18. Implementation Issues
Real-time Support:
Use of websockets
Many-to-one messaging
Use of Publish/Subscribe protocol (XMPP,
MQTT, Redis,?)
REV2011 Conference, Brasov, Romania
19. Short Demonstration
Implemented in JavaScript
Uses RESTful interface
Uses websockets via socket.io for
backwards compatibility
Replaced the Time-of-Day with a Twitter-
feed filter
No authentication & authorization
REV2011 Conference, Brasov, Romania
20. Thank You
&
Comments/
REV2011 Conference, Brasov, Romania
Notes de l'éditeur
\n
Based on experience developing iLab experiments over the last 5 years.\n\nLabVIEW is not an opensource project\n
\n
Strength of SB: allows scaleable management, e.g., currently 1,500 high school students on RadLab, planning for 5,000.\nOther services are available, but not featured in this general overview: experiment storage, scheduling service, \n
must login to SB, select experiment and then launch.\nRequires the each service broker to hold a copy of the client - makes discovery, distribution, sharing and updates difficult.\n
\n
\n
\n
\n
If done in the labserver, it is implementation dependent (i.e., using features of current version of LabView)\n
Could use a shared desktop (e.g., VNC) but this is heavy on bandwidth, and gives a poor response for waveforms in some cases.\n
\n
Progress bar - could be for job queue and a separate one for the status of current batch or interactive experiment\nExperiment data could not only be streamed into an experiment storage service but to other applications at the same time\n
RESTful semantics well defined - methods, caching etc.\n\n\n
Using SOAP on top of a server side JS defeats most of the benefiyts of event driven programming. This may be a show stopper if we don’t maintain the SOAP link and thus want to link with existing service brokers and lab servers.\n
Large and growing number of support libraries, even SOAP support.\n
Unresolved, but will run experiments to determine efficacy and interoperability issues\n
Websockets gets real-time messages in/out of browser but does not define the protocol. This needs to be developed.\nPub/Sub can be handled by XMPP and MQTT, and also in new systems like Redis\n