Design & Implementation Issues in a Contemporary Remote Laboratory Architecture
Upcoming SlideShare
Loading in...5
×
 

Design & Implementation Issues in a Contemporary Remote Laboratory Architecture

on

  • 501 views

A short talk given at the Remote Engineering and Virtual Instrumentation 2011 conference in Brasov, Transylvania, Romania June 28-July 1, 2011.

A short talk given at the Remote Engineering and Virtual Instrumentation 2011 conference in Brasov, Transylvania, Romania June 28-July 1, 2011.

Statistics

Views

Total Views
501
Views on SlideShare
501
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Apple Keynote

Usage Rights

CC Attribution-NonCommercial LicenseCC Attribution-NonCommercial License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \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

Design & Implementation Issues in a Contemporary Remote Laboratory Architecture Design & Implementation Issues in a Contemporary Remote Laboratory Architecture Presentation Transcript

  • Design & Implementation Issues in aContemporary Remote Laboratory Architecture Mark Schulz, CEIT & Adam Rudd, School of ITEE & CEIT The University of Queensland REV2011 Conference, Brasov, Romania
  • Why undertake this project?Enhance the user experienceProduce open source code REV2011 Conference, Brasov, Romania
  • Format of TalkReview of iLab ArchitectureIndicate some limitationsPropose some desirable enhancementsLook at some possible implementationissuesVery short demonstration REV2011 Conference, Brasov, Romania
  • Review of iLab ArchitectureSer vice Oriented Architecture based onWeb ServicesThree 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
  • Limitations of iLab ArchitectureSERVICE BROKER: Authentication & Authorisation are not a ser vice Client is launched from the SB. REV2011 Conference, Brasov, Romania
  • REV2011 Conference, Brasov, Romania
  • REV2011 Conference, Brasov, Romania
  • REV2011 Conference, Brasov, Romania
  • Limitations of iLab ArchitectureDevelopment 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
  • Limitations of iLab ArchitectureNo built-in support for real-timemessaging. 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
  • Limitations of iLab ArchitectureNo architecture support for distributedcollaboration around the client.Current model is collaboration around asingle remote client - requires physicalpresence.This is NOT about chat sessions andshared whiteboards, although these wouldform part of this approach. REV2011 Conference, Brasov, Romania
  • 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
  • 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
  • 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
  • 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
  • Implementation Issues nodejs.org REV2011 Conference, Brasov, Romania
  • 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
  • Implementation Issues Real-time Support: Use of websockets Many-to-one messaging Use of Publish/Subscribe protocol (XMPP, MQTT, Redis,?) REV2011 Conference, Brasov, Romania
  • Short DemonstrationImplemented in JavaScriptUses RESTful interfaceUses websockets via socket.io forbackwards compatibilityReplaced the Time-of-Day with a Twitter-feed filterNo authentication & authorization REV2011 Conference, Brasov, Romania
  • Thank You & Comments/REV2011 Conference, Brasov, Romania