Home | Download/Install | Documentation | Packages | Screenshots | News | Forum/Mailing-lists | Contact | GForge

Openalea client and server V1

* Author : Daniel BARBEAU * Date : 10/10/2011ng the

This document is a draft. Ideas a probably still a bit unstructured. Some nice SVG drawings will also come to beautify this place.

Overview

This document is a design proposal to the implementation of Openalea In The Browser. It features ideas for:

  • HTML5 Visualea Web client
  • Distributed computing
  • Hybrid (local/remote) and distributed node execution
  • Sandboxed execution
  • Compile-once run everywhere

The design is modelled after Model-View-Controller (MVC) and Client-Server design patterns.

Scenarii

In this proposal we consider three use-cases stemming from proposal 200:

  1. Fully Online : The user manipulates a dataflow in the browser but the dataflow is hosted on a remote server and execution is distributed by the server to execution servers. Communication between the browser and the server is done over the internet over the HTTP protocol.
  2. Fully Local : The user manipulates a dataflow in the browser but the dataflow is hosted on a local server and execution is distributed by the server to local execution servers. Communication between the browser and the server is done over the localhost loopback over the HTTP protocol.
  3. Hybrid ( also allows to work offline ) : The user manipulates a dataflow in the browser but the dataflow is hosted on a local server and execution is distributed by the server to execution servers that can be local on user demand. Communication between the browser and the server is done over the localhost loopback over the HTTP protocol. A mecanism is in charge of downloading executable code and caching it.

Entities

Here is a list of entities playing a role in this design (names are not definitive):

  • Package : A group of nodes/composite nodes. There can be user nodes, system nodes.
  • User : has an account where he drops his packages, composite nodes, nodes. Can share them with others.
  • DataflowServer (PackageManager) : Lists and serves packages, composite nodes and nodes. Manage execution of dataflows.
  • ViewServer : Serves HTML5 views for composite nodes and package lists.
  • Executer : Represents a computer (a node in a grid/cluster) - somewhere where computations can take place.
  • CodeCache : Executable (python/binary) code is stored here, accessible by id+version. See Compile Once Run Everywhere
If you want details in how these entities were inferred, click below:

Click to display ⇲

Click to hide ⇱

Click to hide ⇱

Mapping Visualea To MVC

MVC is a common pattern in desktop applications and Visualea uses it :

  • Model : Roughly, it is the in-memory representation of the business data. In Visualea this is probably a dataflow (CompositeNode).
  • View : It is a visual representation of the data, always in sync with it (observer mecanisms). In Visualea it is the dataflowview.
  • Controller : Connects movel to view and directs user events to the Model (often mixed into the view). It is spread across Visualea and dataflowview.

However it is a lot less common in Web design where N-Tiers is the classical solution.

  • Model : In the new design it is the same CompositeNode object.
  • View : In the new design it is a HTML5 (javascript) view (observer mecanism implemented with web technology : XmlHTTPRequest, websockets).
  • Controller : In the new design it is part of the HTML5 view (user events forwarded with web technology : XmlHTTPRequest, websockets).

Mapping Visualea To Client-Server+

The client is what the user interacts with. The server serves what will be interacted on.

  1. In our case we will interact on dataflows so we will need a DataflowServer (in Openalea terms : the PackageManager):
    • lists standard packages, composite nodes and nodes
    • lists shared packages, composite nodes and nodes
    • lists user packages, composite nodes and nodes
  2. We must show to the user what is available on the DataflowServer and a mean to instantiate a composite node:
    • A PackageView (HTML+JS)
  3. We must be able to display and interact with a dataflow:
    • A CompositeNodeView (HTML+JS)
A ViewServer can serve the 2 & 3. ViewServer and DataflowServer can be the same physical server.

However, there is something more. As stated in the scenarii, we want to be able to use Visualea online, offline and a even a mix of both (the user decides what to execute on local and the system fetches the node code to execute). A since the evaluation algorithm allows to distribute the evaluation in a parallel manner we want to be able to run nodes on different physical machines.

  • Online : the user only needs a browser and an online account. The gui (PackageView+CompositeNodeView) is served by the ViewServer. Dataflow execution is run on the remote server, results are stored on the remote server.
  • Offline : the user needs a browser and the ViewServer and DataflowServer must be installed on the local machine. Once browser points to local server the behaviour and implementation can be the exact same as the online version.
  • Hybrid : the user can start building the dataflow online and then move to offline editing and running, or choose that some or all nodes be run locally (to be able to work in the train). The system would then fetch the code to run offline and store it into a CodeStore (identified by some ID and possibly a version number). This includes binary code and we still do not want to manage different systems so we would use Compile Once Run Everywhere. The CodeStore is queried for a node when a node needs to execute.
 
documentation/core/propositions/210_oa_client_server_v1.txt · Last modified: 2011/10/11 10:58 by admin   Back to top
INRIA   INRA     CIRAD     AGROPOLIS IBC
INRIA GForge RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki