Upload
mikolaj-olszewski
View
109
Download
0
Embed Size (px)
DESCRIPTION
In presentation the idea of automatically generated web interface for remote laboratory is presented. The concept is based on suitably prepared set of metadata, that is used to generate web client. In presented solution each remote experiment, sends metadata concerning user interface just before experiment session is started. Main advantages of this solution include: easier deployment and decreased development costs. This concept can be applied for various e-learning areas. The working example of such interface is shown and discussed.
Citation preview
The metadata driven e-laboratory
web client
Mikołaj OlszewskiJacek Bzdak
Outline
1. Idea2. Metadata driven laboratory3. Protocol Details4. Demo5. Benefits
IdeaHow it started...
Introduction• SILF is a remote laboratory developed in a
project: “e-physics - the multimedia environment of teaching physics for upper secondary schools”
• We are to develop 13 remote experiments in 3 years
• We wanted to decrease per-experiment development costs
SILF characterisation
• Experiment servers written in Python• Experiment client is written in Coffeescript,
and requires only a browser to work • Communication is done via the XMPP
protocol• We use XMPP moderation tools
• Every experiment session is done via XMPP group chat room
SILF Architecture
Detailed view of SILF architecture
Terminology
Components - before
• Experiment server• One per experiment, though we have some
driver reuse
• Experiment client• Previously we had a plugin architecture, each
experiment had a client plugin
• Messaging server• One per laboratory
What if we had single client?
• 50% less work on experiment • Yet, much more work on the infrastructure
• Simplified deployment• Client updated without any changes to the
WWW server
• Free lunches• Updates to the client are automatically visible in
all the experiment
Metadata driven laboratoryThe conclusion...
Metadata driven laboratory
• User gets a description of the experiment from the experiment server
• HTML5 Client is responsible for rendering GUI according to the description
Why Web GUI?
• HTML5 powerful enough• Real-time communication via websockets• Works everywhere - everyone has a browser
• but not (for example) Windows• works on mobile devices - responsive layout
• Social networks seamless integration• It is simple and natural for modern people• Easy to upgrade - SaaS model
Example experiment session
• Experiment modes - way to decrease inter control dependences
• Experiment description can be different for each mode
Currently supported metadata
• List of modes • Controls
• label• type• validations
• Results• name • method of display
• It’s enough
Protocol detailsLet’s see how it works underneath...
Protocol details
• XMPP dialect• 100% XMPP compliant!• <labdata> in group chat message• Action defined by namespace• Types: query, result, error• Various content in JSON
Protocol documentation
Experiment conversation
1. Mode selection2. Input validation 3. Session start4. Incoming results5. Session ends6. Experiment ends or go to 1
Conversation details
Mode selection
USER<labdata xmlns="silf:mode:get" id="query1" type="query" />
Experiment<labdata xmlns="silf:mode:get" id="query1" type="result">
{
"lead": {
"label": "Ołów", "description": "Badanie osłabienia w ołowiu", "order" : "1"
}
}</labdata>
Mode description
• label - human readable name
• description human readable
• unique id - name of the mode (machine readable)
Mode setting
USER<labdata xmlns="silf:mode:set" id="query2" type="query">
{"mode": "default"}
</labdata>
Server<labdata xmlns="silf:mode:set" id="query2" type="result">
GUI description
</labdata>
Experiment metadata
{
"experimentId": "urn:uuid:a12e6562-5feb-4046-b98f-d8c40ca1609c",
"mode": "aluminium",
"settings": {
"acquisition_time": {...},
"light": {...}
},
"resultDescription": {
"time_left": {...},
"chart": {...}
}
}
experiment settings
results / outputs description
Control properties
• name - machine readable and unique id
• label - human readable• type - type of the value
(int, timedelta)• validations - bounds to
values
Output field description
• name - of the data source
• type - data type• class - styling• metadata - human
readable metadata
Settings validation
USER<labdata xmlns="silf:settings:check" id="query3" type="query">
{
"acquisition_time": {"value": 150, "current": true},
"light": {"value": false, "current": false}
}
</labdata>
SERVER<labdata xmlns="silf:settings:check" id="query3" type="result"/>
or error message (omitted)
Series startUSER<labdata xmlns="silf:series:start" id="query4" type="query">
{"acquisition_time": {"value": 150, "current": false} … }</labdata>
Experiment<labdata xmlns="silf:series:start" id="query4" type="result">
{
"metadata": {"label": "Czas pomiaru 90s."},
"initialSettings": {
"acquisition_time": {"current": false, "value": 90},
"light": {"current": false, "value": false}
},
"seriesId": "urn:uuid:6bd8a024-5a8b-4f04-be84-76dcad89d89f"
} </labdata>
Series start data
• metadata - human readable metadata
• seriesId - unique series id (needed for storage and retrieval of data)
• initialSettings - settings that were sent by the user to initiate series
ResultsSent by the server when ready<labdata xmlns="silf:results" id="query5" type="result">
{
"chart": {
"value": [[1, 1234], [5, 321]],
"pragma": "append"
},
"time-left": {
"value": [1],
"pragma": "transient"
}
}</labdata>
No response needed
Results
• name of result block• value - value• pragma - controls
data storage and presentation
End of series
Series ends when: • Experiments finishes the
measurements• Operator stops the series • Timeout has occured• Messages are slightly
different for each case
USER<labdata xmlns="silf:series:stop" id="query6" type="query"/>
Server<labdata xmlns="silf:series:stop" id="query6" type="result"/>
End of experiment
Experiment ends when: • Operator stops the
experiment • Timeout has occured
(experiment idle for too long)
• Messages are slightly different for each case
USER<labdata xmlns="silf:experiment:stop" id="query7" type="query"/>
Server<labdata xmlns="silf:experiment:stop" id="query7" type="result"/>
Protocol
• That is all• Less than 10 message types • Yet a fully operational laboratory
DemoThat’s what tiggers do best...
Benefits
• There is one single client• Existing experiments "get features" as we
develop the client• Easy to develop automatically controlled
experiment (working in showcase mode)• Easy (for example) to build Android client• Possible to create server in C/C++/Java/your
favorite language
Epilogue
• Whole framework is open-sourced• Rest of laboratory is being open-source
• Refer to the documentation for details• See also our repositories• This presentation: http://tnij.org/silf|vu2014
Thanks for your attention