Webinaire erocci le 15 mai 2014: découvrez le framework REST 2.0

Posté par  (site web personnel) . Édité par Benoît Sibaud, palm123, ZeroHeure, Nÿco et Nils Ratusznik. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
5
9
mai
2014
Technologie

erocci est un framework générique OCCI (Open Cloud Computing) Interface) écrit en Erlang/OTP (Open Telecom Platform, la bibliothèque standard du langage de programmation Erlang).

Le standard OCCI est un standard ouvert, défini par l'OpenGridForum, pour définir des API REST autour du cloud computing, de manière plus contrainte, et donc facilement interopérables.

Plus de détails dans la suite de la dépêche. Et si vous n'avez pas tout compris, mais que cela titille votre curiosité, nous présenterons erocci lors d'un webinaire organisé par OW2 le 15 mai. Vous pourrez y voir erocci tourner en vrai et poser des questions à l'auteur. Les inscription se passent sur le site d'OW2.

Au fait, pourquoi REST ?

Si le cloud computing a adopté les architectures orientées ressource comme paradigme, et les API REST comme technologie, la grande liberté de mise en oeuvre des API REST rend difficile l'interopérabilité entre ces différentes API: le typage des ressources, le format même des données (JSON, XML, text, etc) n'est pas défini par REST.

Et les standards, n'y en a-t-il pas déjà pléthore ?

Les nombreux standards existants dans le cloud se limitent à fixer un format de données et un vocabulaire pour un domaine particulier: IaaS, authentification, etc. Le standard OCCI adopte, à cet égard, une approche différente puisqu'il définit un méta-modèle ou pour faire simple, une manière unique de typer les ressources et d'exprimer des relations entre elles. Ensuite, OCCI définit une manière unique de le représenter dans les formats de données les plus courants et de les transporter sur différents protocoles réseau : HTTP, XMPP, etc.

Ok pour OCCI, mais quid d'erocci ?

erocci est une mise en oeuvre de OCCI complètement générique. Le modèle (les types de ressource) est décrit avec un fichier XML et peut donc être échangé avec d'autres mises en oeuvre. Ensuite, le développeur devra juste choisir un listener (un protocole réseau) parmi HTTP, HTTPS ou XMPP et un backend pour stocker ses objets. Aujourd'hui le seul backend disponible est basé sur mnesia, la base de données distribuée de Erlang. Cependant, l'API pour développer un backend erocci est aussi simple que mettre en oeuvre les opérations CRUD.

erocci est écrit en Erlang pour la stabilité, la montée en charge et la performance. Néanmoins, si vous utilisez un backend existant, aucune ligne de Erlang n'est nécessaire pour développer sa propre API REST.

Plusieurs backends peuvent être utilisés en même temps dans erocci. Les backends s'attachent comme un système de fichier dans l'arborescence du serveur. Grâce à Erlang, les requêtes vers plusieurs backends s'effectuent en parallèle, avec gestion des pannes (NdM: d'après la documentation, un backend est considéré comme hors service après un délai configurable).

La feuille de route

Le projet, bien que jeune, est déjà fonctionnel même si la feuille de route est bien remplie:

  • gestion des droits, unifiée entre HTTP et XMPP et potentiellement extensible à d'autres protocoles ;
  • intégration avancée de XMPP pour la gestion des groupes, de la présence, etc.
  • développement d'un listener XMPP comme composant XMPP : aujourd'hui le listener XMPP est un client XMPP mais les composants XMPP permettraient de faciliter le développement de passerelles entre OCCI et d'autres API.

Aller plus loin

  • # Merci...

    Posté par  (site web personnel) . Évalué à 2.

    …aux modérateurs pour la petite intro.

    "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

  • # Question ?

    Posté par  (site web personnel) . Évalué à 2.

    ça inclue un support CDMI pour la partie couche donnée ?

    • [^] # Re: Question ?

      Posté par  (site web personnel) . Évalué à 1.

      Non, le protocole CDMI n'est pas pris en charge. La spécification OCCI Infrastructure prévoit une sorte de passerelle depuis un storage OCCI vers un container CDMI.

      Par contre, on peut facilement envisager un schéma OCCI qui ressemble à l'API CDMI, mais en étant 100% compatible OCCI: typage, basé sur les catégories, etc.

      J'en ai commencé un ici d'ailleurs: OCCI Storage schema. J'ai mis en oeuvre ce schéma dans un backend erocci que je placerais très bientôt dans le dépôt github. Ça permet d'exposer un filesystem avec une sémantique OCCI. Une espèce de WebDAV à la sauce OCCI…

      "Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.