the metadata driven e-laboratory web client

Post on 01-Jul-2015

110 Views

Category:

Software

0 Downloads

Preview:

Click to see full reader

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.

TRANSCRIPT

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

top related