Design & Implementation Issues in a Contemporary Remote Laboratory Architecture
•Transferir como KEY, PDF•
1 gostou•1,116 visualizações
A short talk given at the Remote Engineering and Virtual Instrumentation 2011 conference in Brasov, Transylvania, Romania June 28-July 1, 2011.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (11)
Destaque
Semelhante a Design & Implementation Issues in a Contemporary Remote Laboratory Architecture
Semelhante a Design & Implementation Issues in a Contemporary Remote Laboratory Architecture (20)
Último
Último (20)
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
- 6. REV2011 Conference, Brasov, Romania
- 7. REV2011 Conference, Brasov, Romania
- 8. 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
- 16. Implementation Issues nodejs.org 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
Notas do Editor
- \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
- \n
- \n