Runtime : 20 Mo (en plus de .NET et XP), composé du CCR (Concurrency and Coordination Runtime) → distribution des ressources à tous les processus et du DSS : assure la com' entre les services. Un process par noeud (=runtime), composé d'au moins 2 threads (le runtime et les services). Possibilité d'isoler un service dans un thread séparé + possibilité d'isoler les services critiques en dehors du DSS.
Une couche objet
Environement de developement ← choix du langage, simulation, mode de dev “à la Simulink”
Architecture très décentralisée, complètement asynchrone : des services discutent entre-eux. ← Besoins synchrones : ça va au dela de ce qui concerne Robosoft. Damien dit : “On ne sait pas faire”.
Dans MRS, un service a :
un état structuré
un comportement
un ensemble de “partenaires”
des contrats → inscription des contrats dans un repository central. Plus ou moins “l'activité” du service ← utilisation de messages (get, query, submit, subscribe, update…)
Les services peuvent facilement “logger”
Les échanges de messages entre services reposent sur DSSP (du SOAP “light”), qui s'apparente à des Webservices “lights” (mais ce n'est pas directement compatible avec ces derniers). Les services envoient et receptionnent leurs messages via le runtime MRS (qui sert de pile (queue) ).
Système de “Discovery” à l'intérieur du robot. Pour faire du remote sensing ou remote actuating, il faut développer sa couche “Webservice”. A vérifier cependant.
Tout ça ressemble beaucoup au framework open-source écrit en Java JADE.
imara/platforms/software/mrs.txt · Last modified: 2011/02/08 11:38 by Paulo RESENDE
