Écrire pour toujours, consommer vite

La structure de persistance de Kafka s’appuie sur le slogan Don’t fear the filesystem ! qui suit la tendance de certaines applications, comme Varnish, fortement contraintes par une stabilité de leurs performances en écriture et par la confiance accordée au disque dur plutôt qu’à la mémoire vive du serveur pour maintenir les données. L’idée vient du constat que l’écriture en RAM peut avoir des comportements difficilement prévisibles dus par exemple au garbage collection sur de grands heap spaces alors que l’écriture en append only sur un fichier peut être très performante tout en assurant un temps constant. L’article qui a inspiré Kafka décrit avec plus de détails ces aspects.

Ce principe se concrétise dans Kafka par l’écriture des messages dans des fichiers de logs, appelés aussi partitions, où chaque ligne contiendra un en-tête assez réduit (essentiellement le checksum) et le message sous forme de string ou encodé avec un serialiseur de son choix (Kafka prend l’exemple d’Avro). La taille de ces fichiers, le nombre de roulements et leur durée de vie sont configurables. Kafka va même plus loin en proposant de configurer la durée et/ou la taille maximale du buffer dans le page cache. Les messages sont donc écrits séquentiellement et sont gardés pour une durée déterminée par l’utilisateur qui n’a pas de raison de supprimer des messages tant qu’il a de l’espace sur le disque dur. Par contre il n’est pas possible d’écrire au milieu d’un fichier ou de supprimer unitairement un message. Cette règle garantit l’efficacité de l’écriture.

Ce design apporte un avantage immédiat : il n’y a plus de crainte à avoir lorsqu’on arrête un serveur, il peut récupérer l’ensemble de ses messages au redémarrage. De plus, il a la possibilité de relire la file de messages autant de fois qu’il le veut, il lui suffit de parcourir à nouveau les fichiers de logs, et ce, même plusieurs jours après.

Les ingénieurs de Kafka sont partis également du postulat que LinkedIn avait surtout besoin de gérer un gros volume de messages, qu’il y aurait toujours au moins un consommateur et qu’il fallait donc privilégier la consommation à la production. Dans l’architecture, cela se concrétise par deux points :

• l’envoi d’un ensemble de messages (MessageSet) plutôt que de messages unitaires, ce qu’on peut faire en JMS avec les regroupements logiques sur la propriété JMSXGroupId du message;
• l’utilisation de l’API Java NIO et plus particulièrement la méthode FileChannel.transferTo qui permet de sauter l’étape d’écriture dans un buffer côté applicatif et donc d’écrire plus rapidement sur le réseau.

Penser distribué

La gestion des messages sur des serveurs distribués est au cœur de la conception de Kafka. Ce choix est un vrai atout pour la scalabilité de l’application mais complique par ailleurs la compréhension des concepts sous-jacents. Les enjeux étaient de pouvoir augmenter la capacité des serveurs en ajoutant de nouveaux nœuds de façon transparente. Si la quantité de messages augmente, la seule contrainte pour Kafka est d’augmenter l’espace de stockage, ce qui en général ne pose plus de problème dans nos datacenters.

La distribution est en grande partie assurée grâce à Zookeeper, le service de coordination centralisé d’Apache. Les différents serveurs Kafka communiquent avec Zookeeper pour signaler la topologie du cluster, que ce soit le nombre de partitions qu’ils gèrent ou leur taille.

De même chaque client s’enregistre dans Zookeeper et peut former des groupes. Un groupe peut être vu comme une queue en JMS, chaque consommateur du même groupe dépilant le même ensemble de messages, ce qui revient à faire du multithreading sur des queues. Si on veut que deux consommateurs lisent indépendamment cet ensemble de messages, comme on aurait plusieurs subscribers sur un même topic, il suffit de créer deux groupes.

S’il n’est pas évident de calquer notre vision traditionnelle queue/topic sur la conception de Kafka, c’est qu’il n’existe pas de notion de file de messages, mais plutôt de partitions de fichiers distribuées sur plusieurs serveurs. Il est pourtant assez important de comprendre ces concepts sinon on pourrait passer à côté de certains messages !

Faire moins mais le faire bien

Il existe un certain nombre de fonctionnalités courantes dans les MOM qu’on ne retrouvera pas dans Kafka. Quelques-unes d’entre elles:

• pas d’acquittement : il n’y a pas de certitude que les clients ont tous consommé chaque message (voir le prochain chapitre);
• pas de sélecteur comme en JMS, un client s’abonne juste à un sujet donné. En effet, on ne retrouve que des informations techniques dans le header du message, comme sa taille ou le CRC. Ce qui fournit peu d’éléments pour filtrer tel ou tel message;
• pas de request/reply : comme le point précédent, le message ne contient pas d’identifiant de corrélation.

Cette minimisation des fonctionnalités est le prix à payer pour favoriser avant tout le débit des messages. Dans un MOM “classique”, pour s’assurer que tous les consommateurs d’un topic ou d’une queue ont bien récupéré leurs messages suivant les différents scénarios possibles (auto acknowledgement, client acknowledgement, transactions…), les serveurs auront besoin de maintenir des états complexes. A cela, on peut ajouter la persistance des messages ou la contrainte d’au plus un envoi et on imagine assez bien où les serveurs peuvent perdre du temps.

Kafka prend les choses beaucoup plus simplement. Le serveur écrit le message sur une de ses partitions et ensuite le consommateur retrouve cette partition pour y lire le message. Par ce design assez simple en apparence, Kafka résout facilement les problématiques d’ordonnancement des messages.

Consommer intelligemment

Comme nous l’avons vu précédemment, Kafka ne possède pas de notion d’acquittement. Ce concept est remplacé par celui d’offset. Cet offset représente le high-water mark pour un consommateur, c’est-à-dire l’emplacement du dernier message lu dans le fichier de log. Cet offset est géré par le client lui-même, libre à lui de le déplacer manuellement.

Encore une fois Kafka transforme une idée simple en un outil puissant. En effet la gestion manuelle de l’offset permet de reparcourir autant de fois qu’on veut une liste de messages. On imagine assez bien l’utilité dans le cas du crash d’un client par exemple, mais on pourrait aussi imaginer qu’un message déclenche un retraitement des n derniers messages pour les envoyer vers une file de messages d’audit.

Étonnamment, la gestion des transactions côté client devient également assez légère. Par exemple si, à la réception d’un message, le client doit persister des informations dans une base de donnée, à l’intérieur d’une transaction, l’offset peut également être persisté en base dans cette même transaction. Par conséquent, en cas de rollback de la transaction, le client récupérera l’ancien offset et pourra tenter de reconsommer le même message.

Alors, on se lance ?

Est-ce que ça s’adresse à mon projet ?

Est-ce que Kafka peut répondre à vos besoins ? Pour orienter votre choix, nous voyons déjà trois idées fortes qui sous-tendent cet outil :

• les messages sont de la donnée, ce que Kafka appelle l’activity stream data. Dans un MOM classique le message n’a qu’un état provisoire; une fois consommé et acquitté il a pour vocation de disparaître. Dans Kafka, le message reste, peut être relu et renvoyé. Si on pousse le concept jusqu’au bout, il n’est plus réellement nécessaire de stocker ces informations ailleurs (dans des archives de logs ou une base de monitoring par exemple), Kafka peut jouer le rôle de _datasource_;
• une donnée doit pouvoir être consommée immédiatement (alerte de sécurité par exemple) et aussi analysée à froid dans des outils de Business Intelligence sous forme de batch. Avec ce schéma, il n’est plus nécessaire de dupliquer les workflows;
• le volume de données ne doit pas être un problème, je dois pouvoir scaler horizontalement en toute transparence.

Si notre activité contient beaucoup de petites mises à jour, des notifications entre utilisateurs ou des scénarios d’utilisation qu’il est important de savoir rejouer, Kafka est une bonne solution. Il n’est pas étonnant que, outre LinkedIn, les premiers utilisateurs, Tagged et Mate1, soient aussi des réseaux sociaux.

On pourrait aussi imaginer une modélisation pour gérer les flux financiers : d’un côté la mise à jour permanente du cours de la bourse est récupérée par le front office, de l’autre les outils d’analyse de risque, de calcul de PnL (profits et pertes) et d’audit peuvent être déroulés à froid.

La peinture est-elle sèche ?

Lors de nos journées d’échange à Xebia, nous avons pu expérimenter les fonctionnalités de Kafka. La compréhension du workflow a été la difficulté la plus souvent rencontrée. On met du temps à comprendre les concepts et on a la sensation que nos consommateurs relisent les mêmes messages ou au contraire qu’on en perd. La courbe d’apprentissage sera sûrement plus longue que pour utiliser JMS ou AMQP.

Par ailleurs, l’API java proposée n’est pour l’instant pas très riche même si elle permet déjà de faire l’essentiel. Il y a par exemple des méthodes permettant de reparcourir les partitions mais elles sont d’assez bas niveau, on aurait aimé des fonctions de recherches plus poussées. Nous n’avons pas testé l’API Scala (Kafka est écrit en Scala !) mais elle semble plus riche de ce point de vue. Néanmoins il ne s’agit que de la version 0.6 et la roadmap de Kafka contient déjà pas mal d’améliorations qui vont dans le bon sens. Par exemple, l’arrivée de la compression et de la réplication devrait contribuer à la maturité de la solution.

Conclusion

Malgré sa jeunesse, Kafka est sans aucun doute un outil à surveiller. Son passage en projet Apache, s’il passe la phase d’incubation, devrait apporter une meilleure assise en l’ouvrant à de nouveaux cas d’utilisation et en le décloisonnant de l’environnement de LinkedIn. De plus certains projets seront sûrement intéressés par le support d’Hadoop, utilisé également pour leurs besoins en interne.

La complexité de l’architecture peut par contre être un gros frein surtout si le dialogue est difficile avec les équipes opérationnelles. Car même si Zookeeper permet de lier automatiquement les brokers aux consommateurs, il semble préférable que ces derniers connaissent un minimum l’architecture pour certains modes de consommation. De même, pour des questions de performances ou de sécurité, les opérationnels auront peut-être besoin de rapprocher tel serveur à tel producteur ou consommateur de message. Il s’agit d’un vrai défi pour le DevOps.

Néanmoins Kafka apporte un regard nouveau sur un vieux sujet, les MOM, en proposant des solutions radicalement différentes de ce qu’on trouve ailleurs. Peut-être germera-t-il de nouvelles idées pour de nouvelles solutions de messaging ?

Le client JavaScript que nous allons déployer repose sur jQuery — un framework de haute productivité —, nous lui adjoindrons BackboneJS, un framework MVC REST, et RequireJS, un chargeur de modules à la demande.

Ressources et représentations

Le serveur auquel se connecte notre client est une boutique en ligne type Amazon. Elle propose une liste de produits, disponibles en quantité limitée, qu’il est possible de réserver dans un panier client. Deux ressources implémentent ces fonctionnalités :

Ces ressources produisent et consomment les représentations suivantes :

Les produits disponibles dans le stock disposeront, via leur attribut links, d’une relation afin de les ajouter au panier :

Se reporter à l’article connexe pour plus de détails sur les notions de ressource, représentation et relation.

Structure du site

Notre client web est composé d’une simple page html, d’une css et de modules JavaScript. Outre ses headers, la page index.html se résume aux lignes suivantes.

<body>
  <div id="cart"></div>
  <div id="products">
    <div id="product-creation"></div>
    <div id="product-list"></div>
  </div>
</body>

Trois emplacements sont prévus dans cette page sous la forme de div ; un pour le panier client, un autre pour ajouter un produit en magasin, un dernier pour lister les produits existants. Vides lors de l’affichage de la page, ces trois emplacements vont être renseignés par les données serveur via jQuery. Ce dernier permet de manipuler dynamiquement le DOM – le contenu de la page – afin d’offrir une expérience d’utilisation sans rafraîchissement.

La mise en page est simpliste : les produits occupent la majorité de la page, le panier, lui, est confiné dans une « colonne » sur la droite.

#products {margin-right:250px;}
#cart {float:right; width:250px }

Modules externes

Si jQuery fournit d’excellents outils pour manipuler le DOM, il est agnostique quant à la structuration du code ; BackboneJS permet de le structurer en MVC et RequireJS de le découper en modules. Commençons par confier la gestion des dépendances à RequireJS dans le head de la page index.html.

<script
  data-main="js/main"
  src="//ajax.cdnjs.com/ajax/libs/require.js/0.24.0/require.min.js">
</script>

RequireJS, situé sur un CDN (un repository de librairies), est chargé du code JavaScript de notre page. Pour se faire, il a besoin du point d’entrée de l’application, que l’on nommera main.js. Dans ce fichier, on récupère la main via une méthode require. Les bibliothèques externes sont importées – le préfixe order! indique qu’elles seront chargées dans l’ordre de déclaration – puis notre code exécuté.

require({ baseUrl:'/js' },
  ["order!//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js",
   "order!//ajax.googleapis.com/ajax/libs/jqueryui/1.8.13/jquery-ui.min.js",
   "order!//ajax.cdnjs.com/ajax/libs/underscore.js/1.1.6/underscore-min.js",
   "order!//ajax.cdnjs.com/ajax/libs/backbone.js/0.3.3/backbone-min.js",
   "order!/lib/jquery.pubsub.min.js"],
  function()
  {
      // application
  }
);

Une fois les librairies externes importées, les classes de l’application doivent l’être également. RequireJS permet de moduler une application à loisir, nous retiendrons un découpage « une classe par fichier », de nombreux autres sont imaginables. Il est important de noter que ce découpage est un artifice destiné à faciliter le développement, lors de la mise en production les sources RequireJS seront minifiées (compressées et rassemblées au sein d’un même fichier).

require(...,
  function () {
    require(["product/ProductView",
             "product/ProductCollection"],
    function (ProductView,
              ProductCollection) {
      // application
    });
  }
);

Les classes de l’application sont déclarées avec leur chemin et manipulées grâce à un alias. Elles doivent être déclarées dans un fichier distinct comme module RequireJS via une méthode define comme nous allons le voir.

Créer un produit avec POST

Maintenant que la structure du projet est définie, il est temps de connecter le code aux ressources serveur : BackboneJS entre en jeu. Le formulaire de création de produit est le premier élément à ajouter à la page ; en voici le contenu.

<form method="post" onsubmit="return false" class="product">
  <fieldset>
    <ul>
      <li><label>Name: <input type="text" id="name" size="3" /></label></li>
      <li><label>Price: <input type="text" id="price" size="3" /></label></li>
      <li><label>Stock: <input type="text" id="quantity" size="3" /></label></li>
    </ul>
    <input type="submit" value="new product" />
  </fieldset>
</form>

Dans un premier temps, la classe ProductCreationView doit écraser l’emplacement product-creation de index.html avec la template précédente.

La fichier ProductCreationView est déclaré comme module RequireJS par la méthode define qui le nomme et indique sa dépendance à la template (le préfixe text! permet l’accès à un fichier plat). Ce module retourne une classe View héritée de BackboneJS qui sera instanciée par l’appelant.

Une vue BackboneJS définit :

• l’élément du DOM qu’elle manipule (avec jQuery) via la propriété el
• son constructeur via la propriété initialize
• les évènements capturés sur l’élément manipulé via la propriété events

define("ProductCreationView",
  ['text!/template/ProductCreationTemplate.html'],
  function(tmpl){
  return Backbone.View.extend({
    el: $('#product-creation'),
    initialize: function(){
      this.el.html(tmpl);
    }
  });
});

Le $ est un alias jQuery. Il donne accès à toutes les méthodes du framework ; avec une chaîne en argument, il joue le rôle de sélecteur. Il identifie un élément du DOM et permet de remplacer son contenu avec el.html(value). Le #, issu du monde css, représente l’attribut id d’une balise html (l’attribut class est représenté par un point, « . »).

Lorsqu’une instance de cette vue est créée, son constructeur écrase l’élément DOM à l’id product-creation et le remplace par le contenu de la template.

define("ProductCreationView",
  function(...){
    events: {
      "click input:submit": "create"
    },
    create: function() {
      var name = $('#name');
      var price = $('#price');
      var quantity = $('#quantity');
 
      this.collection.create({
        name: name.val(),
        price: price.val()
      });
    }
  });
});
 
define("ProductCollection", [], function(){
  return Backbone.Collection.extend({
     url: '/resource/product'
  });
});

Ensuite, lors du clic de l’utilisateur sur l’input submit de la template, la méthode create capture la valeur des inputs text Name, Price et Stock et délègue la création du produit à une collection (héritée de la Collection BackeboneJS). Cette dernière déclenche un POST sur la ressource /product avec la représentation qui lui est transmise.

Le fichier main.js déclare les deux classes ProductCollection et ProductCreationView, les instancie, et communique la collection à la vue afin qu’elle puisse créer un nouvel élément dans celle-ci (BackboneJS ne dispose pas de contrôleur à hériter). La méthode start est le bootstrap de l’application RequireJS.

require(...,
  function () {
    require(["product/ProductView",
             "product/ProductCollection"],
    function (ProductView,
              ProductCollection) {
      return {
      start: function() {
        var products = new ProductCollection();
        new ProductCreationView({ collection: products });
      }
    }
  }
);

Récapitulons :

1. la page index.html est chargée par le navigateur
2. la balise script initialise RequireJS qui donne la main à notre code
3. une collection est instanciée avec une référence à la ressource /product
4. une vue est instanciée avec cette collection
5. cette vue charge la template de création de produit dans index.html
6. lors d’une création de produit par l’utilisateur, la vue appelle create sur la collection de produits
7. la collection de produits POST le produit au serveur et récupère celui retourné pour mettre à jour id et links

L’échange HTTP obtenu est le suivant :

# Request
POST /resource/product HTTP/1.1
Host: localhost:8080
Content-Type: application/json;q=1.0
{
  "name":"pull",
  "price":25
}
 
# Response
HTTP/1.1 201 CREATED
Content-Type: application/json
{
  "id":0,
  "name":"pull",
  "price":25,
  "links":[{
    "href":"resource/product/0/stock/{quantity}/{username}",
    "rel":"RELS_BOOK"
  }]
}

Lister les produits avec GET

Maintenant qu’il est possible d’ajouter des produits via l’interface, voyons comment les afficher ; un emplacement est prévu à cet effet, celui à l’identifiant product-list.

<form method="post" onsubmit="return false">
  <fieldset>
    <ul>
      <li><strong><%= product.get('name') %></strong></li>
      <li>Price: $<%= product.get('price') %></li>
      <li>
        <label>
          Qty: <input type="text" data-id="<%= product.get('id') %>" value="1" size="3"/>
        </label>
      </li>
    </ul>
 
    <input type="submit" data-id="<%= product.get('id') %>" value="add to cart" />
  </fieldset>
</form>

La template précédente permet l’affichage d’un produit, elle utilise la syntaxe UnderscoreJS <%= value %> (utilisé également par BackboneJS ; il existe de nombreux moteurs de templates, MustacheJS, entre autres). Elle est intégrée à la page grâce au code de la classe ProductView qui lui transmet un produit en paramètre. Le produit étant issu d’une collection BackboneJS, accéder à une propriété passe par un getter.

define("ProductView",
  ['text!/template/ProductTemplate.html'],
  function(tmpl){
  return Backbone.View.extend({
    el: $("#product-list"),
    initialize: function(){
      _.bindAll(this, 'render');
      this.collection.bind('add', this.render);
    },
    render: function() {
      var template = '';
      this.collection.each(function(product) {
        template += _.template(tmpl, { product: product });
      });
      this.el.html(template);
    }
  });
});

Le constructeur de cette classe positionne un écouteur sur l’ajout d’élément à la collection de produits avec bind. L’occurrence de cet évènement déclenche la propriété render de la vue. Cette écoute étant effectuée par la collection, le this manipulé par la méthode render de la vue lui est relatif. L’utilisation d’une méthode utilitaire d’Underscore, bindAll, permet de modifier ce comportement en indiquant que le this manipulé par la méthode render est la vue elle-même.

L’ajout d’un produit à la collection manipulée par cette vue ajoute une template pour chaque produit à la page. Les collections BackboneJS offrent une méthode each pour faciliter l’itération sur leurs éléments. Lorsque plusieurs éléments sont ajoutés à une page, il est plus performant de les concaténer et de les afficher d’un coup.

L’identifiant du produit est positionné sur l’input submit afin de localiser le produit sélectionné par le client par la suite. L’input text recevant la quantité réservée le reçoit également à cette fin.

Réserver une quantité d’un produit

Afin de permettre la réservation d’une certaine quantité d’un article, il est nécessaire d’ajouter le code suivant à la classe ProductView :

define("ProductView",
  function(...){
  return Backbone.View.extend({
    events: {
      "click input:submit": "book"
    },
    book: function(event) {
      var product_id = $(event.target).data('id');
      var quantity = $('input[type=text][data-id="'+product_id+'"]').val();
 
      var links = this.collection.get(product_id).get('links');
 
      var map = new Object();
      _.each(links, function(link) {
        map[link.rel] = link.href;
      });
 
      $.ajax({
        type: 'POST',
        url: map['RELS_BOOK'].replace('{quantity}', quantity).replace('{username}', "xebia"),
        success: function() {$.publish('basket-event')},
        error: function(xhr) { alert(xhr.responseText) }
      });
    }
  });
});

Le clic sur l’input submit de la vue est capturé et son évènement déclencheur permet d’identifier quel produit, parmi la liste proposée, a été sélectionné : event.target permet d’accéder à l’input submit qui a reçu le clic. Il est alors possible de récupérer ses attributs, ici son data-id (cet identifiant est préférable à id car il est utilisé pour deux éléments, la quantité et le bouton submit). Les collections BackboneJS offrent une méthode get(id) permettant d’accéder à un élément par son identifiant. La quantité est récupérée à l’aide d’un sélecteur jQuery.

Les relations proposées par le produit sélectionné sont copiées dans une map, et la template de réservation d’un produit est complétée (quantity et username). Un POST est réalisé sur le lien obtenu.

Afficher le panier

Lors du succès d’une réservation, le panier doit être rafraîchi. La ressource /product ajoute un ou plusieurs produits dans le panier utilisateur, représenté par la ressource /basket. La ressource /basket ne remonte donc aucune notification au client, puisqu’elle est modifiée côté serveur. Il donc nécessaire, comme le fait le handler success de l’appel de réservation, de publier un évènement lors du succès d’un achat à destination du panier afin qu’il se rafraîchisse. Cette gestion d’évènements est ajoutée à jQuery par Tiny Pub/Sub.

define("BasketView",
  function(...) {
  return Backbone.View.extend({
    el: $('#cart'),
 
    var view = this;
    $.subscribe('basket-event', view.fetch);
  },
  fetch: function() {
    var view = this;
    this.model.clear();
    this.model.fetch({ success: view.render });
  },
  price:0,
  render: function() {
    var stocks = this.model.get('stock');
    var view = this;
    var tmpl = '';
    var total = 0;
 
    _.each(stocks, function(stock) {
        var product = view.collection.get(stock.id);
        var price = stock.quantity * product.get('price');
        total += price;
        tmpl += _.template(basketItemTemplate,
                          { quantity: stock.quantity,
                            name: product.get('name'),
                            price: price });
    });
    this.el.html(_.template(basketTemplate, { total: total }));
    $('tbody', this.el).html(tmpl);
    this.price = total;
  });
});

Deux templates sont nécessaires à l’affichage du panier : un tableau et un élément répété pour chaque produit. Le calcul du prix du panier est effectué côté client ; lors d’un clic utilisateur sur le bouton « checkout » le prix est comparé à celui retourné par le serveur et, s’il est correct, le payement est effectué et le panier vidé (la comparaison du prix et son calcul côté client sont, bien entendu, réalisés à des fins didactiques).

define("BasketView",
  function(...) {
  return Backbone.View.extend({
    events: {
      "click input:submit": "checkout"
    },
    checkout: function() {
      var links = this.model.get('links');
      var map = {};
 
      _.each(links, function(link) {
        map[link.rel] = link.href;
      });
 
      var total = this.price;
      $.getJSON(map['RELS_PRICE'], function(response) {
        if(response.value == total)
          $.post(map['RELS_PAYMENT'], function() { $.publish('basket-event') });
      });
    }
  });
});

Épilogue

L’interface unifiée de HTTP offerte par BackboneJS simplifie grandement l’interaction avec un serveur REST (en plus des exemples présentés ici, la modification d’un élément déclenche un PUT, sa suppression un DELETE). L’utilisation d’une liste de relations, plutôt que d’URI, entre client et serveur diminue encore leur couplage. Pour approfondir le sujet davantage, se référer à l’article de référence sur l’intégration des solutions jQuery dans l’entreprise.

Une fois déployée, la servlet Jersey mappe l’url /resource/* ; la partie cliente est disponible sur /index.html. Le web.xml définit deux filtres Jersey afin de loguer les trames HTTP des échanges client-serveur.

Par convention, GET /product liste tous les produits, GET /product/12 affiche le produit identifié, PUT /product/12 remplace le produit identifié par celui transmit, DELETE /product/12 supprime le produit identifié, POST /product crée le produit transmis et fourni son identifiant en réponse. Les verbes GET, PUT et DELETE sont sûrs et idempotents (sans effet de bord – effet identique à requête identique). POST est utilisé comme factory (ici pour créer de nouveaux produits) et pour toute opération non sûre ou non idempotente (par exemple, déplacer une quantité du stock vers un panier). Les navigateurs internet utilisent abondamment GET pour accéder au contenu d’une page web et POST lors de la soumission d’un formulaire.

Ressources

L’application que nous nous apprêtons à développer est une boutique en ligne type Amazon. Elle propose une liste de produits, disponibles en quantité limitée, qu’il est possible de réserver dans un panier client. Deux ressources implémentent ces fonctionnalités, ProductResource et BasketResource, dont voici les définitions :

Récupérer la liste des produits s’effectue avec un GET sur http://localhost:8080/resource/product.

À l’instar de la navigation sur internet, naviguer entre ressources s’effectue à l’aide de liens. Alors que sur le web c’est le nom du lien qui aiguille l’internaute, ici c’est la relation — l’attribut rel — qui permet de naviguer. HTTP définit des relations standards, pour couvrir les besoins de l’exercice, les suivantes lui sont ajoutées et communiquées au client :

Représentations

Les représentations sont les objets échangés entre client et serveur (en XML ou JSON, à la demande du client). Elles sont définies dans un XSD. Côté serveur, la grappe d’objets équivalente est générée par XJC. Un précédent article aborde les notions de JAXB en détails. Voici une définition compacte des représentations :

La servlet Jersey est initialisée avec le paramètre POJOMappingFeature afin d’utiliser Jackson pour le marshalling JSON plutôt que JAXB, dont la responsabilité est ici limitée au marshalling XML. Jackson produit un JSON plus standard — la dépendance jersey-json est ajoutée au pom.xml.

JAXB requiert l’annotation @XmlRootElement afin de produire/consommer les objets du modèle en XML. Jackson n’en nécessite aucune.

Les représentations et les ressources sont intimement liées. Leur nommage gagne à être cohérent : la ressource /product produit une List lors d’un GET et consomme un Product lors d’un POST ; la ressource /stock produit et consomme un Stock. Sans information (le déplacement d’un produit dans le panier et le paiement), aucune représentation n’est consommée ni produite, seuls l’URI, le statut de retour et les headers caractérisent l’échange.

Status de retour

Quelle que soit l’opération demandée, les ressource indiquent toujours un statut de retour. Ce code, composé de 3 chiffres dont le premier spécifie la catégorie (1. information, 2. succès, 3. redirection, 4. erreur client, 5. erreur serveur), est indiqué à chaque appel de ressource, quel que soit le verbe HTTP utilisé et la présence, ou non, de représentation. 200, 301 et 404 sont les plus connus, ils indiquent, dans l’ordre, un succès, une redirection et l’absence du document recherché. Se référer à la liste des statuts HTTP pour plus de détail.

Headers

Une trame HTTP est composée, en plus d’une représentation — le body — et d’un statut de retour, de headers — l’entête –. Les headers HTTP, une liste de propriétés clé/valeur, en plus de véhiculer la négociation de médiatype, communiquent des informations de cache, de concurrence et de sécurité notamment. Un précédent article aborde les notions d’authentification HTTP en détails.

Ressource produit

L’intégralité du code étant disponible sur GitHub, nous nous focaliserons sur les points clé de l’implémentation. Toute latitude est laissée au lecteur d’aller et venir entre les explications suivantes et le code lié. Afin de simplifier la compréhension, le rôle du référentiel de données est joué par des classes dotées de méthodes statiques, Products, Stocks et Purchases. Commençons avec la classe ProductResource.

import javax.ws.rs.GET;
import javax.ws.rs.POST;
import javax.ws.rs.Path;
import javax.ws.rs.core.Response;
 
@Path("/product")
public class ProductResource {
    @GET
    @Path("/{id}")
    public Response get(@PathParam("id") long id) {
        Product product = Products.get(id);
        return Response.ok(product).build();
    }
 
    @POST
    public Response post(Product product) {
        Products.put(product);
        return Response.ok(product).build();
    }
 
    @GET
    public Response get() {
        List<Product> products = Products.get();
        GenericEntity<List<Product>> entity = new GenericEntity<List<Product>>(products) {};
        return Response.ok(entity).build();
    }
}

L’annotation @Path permet de déclarer l’URI d’une ressource au niveau d’une classe puis de la compléter si nécessaire au niveau méthode (le scannage de Jersey peut être restreint à un package dans le web.xml). Les méthodes HTTP sont représentées quant à elles par des annotations du même nom @GET, @PUT, @DELETE et @POST appartenant au package javax.ws.rs de JAX-RS. Du même package, le builder Response permet notamment de positionner le code de retour (la méthode ok(...) le positionne à 200), la représentation retournée, les headers, etc.

GenericEntity est nécessaire lors de la production d’une List en guise de réponse. Les implémentations de List n’étant pas annotés avec JAXB, cette encapsulation permet de positionner une liste au premier nœud du graphe.

En cas d’absence du produit, une NotFoundException est levée par Products. Cette exception, de la famille des WebApplicationException est capturée par un mapper annoté @Provider. Cette classe d’exceptions introduite par Jersey remonte une réponse avec statut de retour approprié : ici, 404.

La classe Product (générée par XJC) est la représentation consommée et produite par cette ressource ; elle a été réduite ici à sa plus simple expression.

import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlRootElement;
 
@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Product {
    protected long id;
    protected String name;
    protected int price;
    protected List<Link> links;
}

Lors d’un appel à cette ressource le header Accept permet d’indiquer les préférences du médiatype utilisé pour communiquer la représentation. Le navigateur Chrome, par exemple, indique les suivants Accept: text/html,application/xml;q=0.9,/;q=0.8. Ceux-ci sont pondérés, ainsi il préfère XML (0.9) à JSON (0.8, */* indiquant ceux non exprimés auparavant). Il obtient donc la représentation en XML :

<products>
  <product>
    <id>0</id>
    <name>pull</name>
    <price>25</price>
    <links>
      <href>resource/product/0/stock/{quantity}/{username}</href>
      <rel>rels/book</rel>
    </links>
  </product>
</products>

Appelé d’un client JavaScript la représentation sera bien plus compacte, grâce au JSON :

[{
  "id": 0,
  "name": "pull",
  "price": 25,
  "links": [{
    "href": "resource/product/0/stock/{quantity}/{username}",
    "rel": "RELS_BOOK"}]
}]

Ces représentations ont été indentées, sans quoi, elles seraient exprimées sur une simple ligne.

L’échange client serveur peut être simplifié ainsi :

# Request
GET /product HTTP/1.1
Host: localhost:8080
Accept: application/json;q=1.0
 
# Response
HTTP/1.1 200 OK
Content-Type: application/json
[{"id": 0...}]

Tests produit

Afin de s’assurer du fonctionnement de cette première ressource, un serveur Jetty-Embedded peut être déployé et une batterie de tests exécutée à l’aide du client Jersey. Voyons comment avec la classe ProductResourceTest et son référentiel de données Shipments.

import static com.sun.jersey.api.client.ClientResponse.Status.OK;
import static com.sun.jersey.api.client.ClientResponse.Status.NOT_FOUND;
 
import org.junit.Rule;
import javax.ws.rs.core.UriBuilder;
 
import com.sun.jersey.api.client.Client;
import com.sun.jersey.api.client.ClientResponse;
 
public class ProductResourceTest {
  @Rule
  public EmbeddedTestServer server = new EmbeddedTestServer();
 
  @Before
  public void before() {
    for (Product product : Shipments.products())
      productResource().post(product);
  }
 
  @Test
  public void shouldGetProduct() {
    Product product = productResource(2).get(Product.class);
    assertNotNull(product);
    assertEquals(product.getName(), "L'étranger");
  }
 
  @Test
  public void shouldNotGetUnexistingProduct() {
    ClientResponse response = productResource(12).get(ClientResponse.class);
    assertEquals(response.getStatus(), NOT_FOUND.getStatusCode());
  }
 
  @Test
  public void shouldListProducts() {
    ClientResponse clientResponse = productResource().get(ClientResponse.class);
    List<Product> products = clientResponse.getEntity(new GenericType<List<Product>>() {});
 
    assertEquals(OK.getStatusCode(), clientResponse.getStatus());
    assertEquals(Shipments.size(), products.size());
  }
 
  /* helpers */
 
  private WebResource productResource() {
    URI uri = UriBuilder.fromPath("resource/product").build();
    return Client.create().resource(server.uri()).path(uri.getPath());
  }
 
  private WebResource productResource(long productId) {
    URI uri = UriBuilder.fromPath("resource/product/{id}").build(productId);
    return Client.create().resource(server.uri()).path(uri.getPath());
  }
}

L’annotation @Rule permet d’externaliser le lancement du serveur (basé sur le web.xml). L’initialisation réalisée par l’annotation @Before utilise POST comme une factory pour créer, un à un, de nouveaux produits. Les tests utilisent GET pour vérifier la présence de ceux-ci (et leur numérotation côté serveur). Les listes nécessitent l’utilisation de GenericType afin de conserver leur typage.

Le client a généré, au préalable, les représentations avec XJC. Ainsi, il peut demander l’unmarshalling de la réponse à Jersey. On notera l’accès direct à la classe Product dans le premier test et le passage préalable par ClientResponse dans le second, donnant accès, en plus de la représentation de la réponse, à son statut et ses headers. On notera également la gestion de template proposée par UriBuilder dont la méthode build(...) remplace les différents tags.

Ressource stock

La notion de stock d’un produit lui est indépendante. Positionner le stock comme attribut de produit porte à confusion : déplacer un produit du stock vers le panier client ne doit pas concerner tout le stock, seulement la quantité réservée. Pour autant, définir une ressource indépendante /stock/{productid} est ambiguë. Une manière plus élégante est de l’exprimer comme noeud du produit /product/{id}/stock ; cela traduit bien l’appartenance de l’un à l’autre sans impliquer la présence d’un attribut dans la représentation. Les / d’une URL définissent toujours une hiérarchie.

L’implémentation suivante considère l’ajout au stock comme un arrivage et utilise donc POST. Si l’accès au stock avait été considéré comme le remplacement de la quantité existante, PUT aurait été retenu.

import javax.ws.rs.core.Response.Status;
import javax.ws.rs.core.EntityTag;
import com.google.common.base.Objects;
 
@Path("/product")
public class ProductResource {
  @POST
  @Path("/{id}/stock")
  public Response addToStock(@PathParam("id") long id, Stock stock) {
    Integer instock = Stocks.quantity(id);
    Stocks.put(id, instock + stock.getQuantity());
    return Response.status(Status.ACCEPTED).build();
  }
 
  @GET
  @Path("/{id}/stock")
  public Response stock(@PathParam("id") long id) {
    Stock stock = new Stock();
    stock.setQuantity(Stocks.quantity(id));
    return Response.ok(stock).tag(eTag(id, stock.getQuantity())).build();
  }
 
  private EntityTag eTag(long id, int quantity) {
    return new EntityTag(String.valueOf(Objects.hashCode(id, quantity)));
  }
}

L’ajout de stock vérifie au préalable l’existence du produit et renseigne le statut de la réponse en conséquence (Stocks s’en remet à Products qui lève une NotFoundException le cas échéant). La classe-représentation consommée et produite par cette ressource est la suivante.

@XmlRootElement
@XmlAccessorType(XmlAccessType.FIELD)
public class Stock {
  protected int quantity;
  protected long id;
  protected Link related;
}

Lors de l’accès à la ressource stock un tag d’accès concurrent est ajouté aux headers. Ce dernier est calculé à partir du hash de l’id produit et de la quantité disponible. Lorsqu’il veut réserver une certaine quantité du stock, le client fournit ce tag — qu’il estime être le dernier en date — afin que le serveur puisse lui indiquer si la ressource a changé depuis (ici, si la quantité a changé). Si c’est le cas, le client doit la récupérer à nouveau du serveur. Lorsque les deux tags correspondent, le serveur accepte la demande client.

Ce tag peut également permettre 1. de ne pas reconstruire une grappe d’objets côté serveur si le client a déjà sa dernière version 2. de gérer la concurrence de modification d’une ressource.

import javax.ws.rs.core.Request;
import javax.ws.rs.core.Context;
 
@Path("/product")
public class ProductResource {
  @POST
  @Path("/{id}/stock/{quantity}/{username}")
  public Response post(@PathParam("id") long id, @PathParam("quantity") int quantity,
      @PathParam("username") String username, @Context Request request) {
 
    String message;
    int productQuantity = Stocks.quantity(id);
 
    if (request.evaluatePreconditions(eTag(id, productQuantity)) == null) {
      if (Stocks.sell(id, quantity)) {
        Purchases.put(username, id, quantity);
        return Response.ok().build();
 
      } else message = "Product is out of stock";
    } else message = "eTag mismatch";
    return Response.status(Status.PRECONDITION_FAILED).entity(message).build();
  }
}

Lors de la réservation d’un produit, le tag transmis est comparé (par le biais d’une méthode utilitaire de Request) à sa valeur actuelle. Si ce calcul est couteux, la valeur du hash peut être sauvegardée avec l’objet afin d’économiser ce coût. Cette comparaison renvoie un statut 412 si un problème se produit. Ensuite, le stock est décrémenté s’il lui reste assez d’articles (la méthode sell renvoie un booléen acquittant l’opération).

Lorsqu’une erreur se produit, la réponse, en plus du code 412 — préconditions non respectées –, se voit dotée d’un message d’erreur approprié.

Afin de limiter le couplage, le lien de réservation ne sera pas connu par le client. Ce dernier sera averti de l’accès à la réservation par la présence d’une relation rels/book. Cette relation est ajoutée au produit lors de sa création via POST.

@Path("/product")
public class ProductResource {
  @POST
  public Response post(Product product) {
    Products.put(product);
    addBookLink(product);
    return Response.ok(product).build();
  }
 
  static UriBuilder uriBuilder = //
  UriBuilder.fromPath("resource/product").path("{id}/stock/{quantity}/{username}");
 
  private void addBookLink(Product product) {
    Link link = new Link();
    URI uri = uriBuilder.build(product.getId(), "{quantity}", "{username}");
    link.setHref(uri.getPath());
    link.setRel(Rels.RELS_BOOK);
    product.getLinks().add(link);
  }
}

Enfin, une fois une quantité du stock déplacée vers un panier client, une ressource va permettre l’accès au panier d’un client. N’ayant que peu de sens sans le nom du client, ce paramètre est rendu général à la classe.

@Path("/basket/{username}")
public class BasketResource {
  @PathParam("username") String username;
 
  @GET
  @Path("/{product}")
  public Response get(@PathParam("product") long productId) {
    Map<Long, Integer> quantityByProductId = Purchases.get(username);
    Stock stock = new Stock();
    stock.setId(productId);
    stock.setQuantity(quantityByProductId.get(productId));
    return Response.ok(stock).build();
  }
}

Tests stock

Pour incrémenter le stock d’un produit, son id est nécessaire ; mais, comme il est généré côté serveur, il est nécessaire de le récupérer lors de sa création. Par convention, POST retourne toujours l’objet qui lui est soumis décoré au minimum d’un identifiant. La création d’un produit, présentée en tête de cet article, s’appuie sur la classe utilitaire Products associant un id au produit avant de retourner le produit ainsi identifié au client. Voici le cas de test du stock.

public class ProductResourceTest {
  @Before
  public void before() {
    for (Product product : Shipments.products()) {
      product = productResource().entity(product).post(Product.class);
      Stock stock = new Stock();
      stock.setQuantity(2);
      stockResource(product.getId()).post(stock);
    }
  }
 
  private WebResource stockResource(long productId) {
    URI uri = UriBuilder.fromPath("resource/product/{id}/stock").build(productId);
    return Client.create().resource(server.uri()).path(uri.getPath());
  }
}

Ce code reprend l’initialisation précédente et ajoute, pour chaque produit, un stock de 2 unités. Les produits ayant désormais du stock il est possible de tester leur réservation dans le panier d’un client.

import com.google.common.collect.ImmutableMap;
import com.google.common.collect.Maps;
import com.xebia.representation.Rels;
 
public class ProductResourceTest {
  @Test
  public void shouldAccessStock() {
    for (Product product : getProducts())
      assertEquals(2, stockResource(product.getId()).get(Stock.class).getQuantity());
  }
 
  @Test
  public void shouldMoveProductToBasket() {
    String username = "xebia";
    int quantity = 2;
 
    Product product = getProducts().get(0);
    String uriBook = rels(product.getLinks()).get(Rels.RELS_BOOK);
    resource(uriBook, ImmutableMap.of("quantity", quantity, "username", username)).post();
 
    assertEquals(0, stockResource(product.getId()).get(Stock.class).getQuantity());
    assertEquals(quantity, basketResource(username, product.getId()).get(Stock.class).getQuantity());
  }
 
  /* helpers */
 
  private WebResource resource(String href, Map<String, ?> params) {
    URI uri = UriBuilder.fromPath(href).buildFromMap(params);
    return resource(uri.getPath());
  }
 
  private List<Product> getProducts() {
    ClientResponse clientResponse = productResource().get(ClientResponse.class);
    return clientResponse.getEntity(new GenericType<List<Product>>() {});
  }
 
  private Map<Rels, String> rels(List<Link> links) {
    Map<Rels, String> rels = Maps.newHashMap();
    for (Link link : links)
      rels.put(link.getRel(), link.getHref());
    return rels;
  }
 
  private WebResource basketResource(String username, long productId) {
    URI uri = UriBuilder.fromPath("resource/basket/{user}/{id}").build(username, productId);
    return createClient().resource(server.uri()).path(uri.getPath());
  }
}

On notera l’utilisation du lien de réservation, rels/book, proposé par la ressource stock limitant la connaissance du client à la template (quantity, username) qu’il doit poster. En l’absence d’un article par exemple, ce lien peut disparaitre, mettant le client — ignorant l’URI complète — dans l’impossibilité d’effectuer une réservation. Ainsi l’état de l’application et ses possibilités futures sont exprimées par ces relations hypermédia (HATEOAS). Client et serveur partagent la connaissance des transitions, celles-ci étant rendues disponibles par le serveur lors de l’accès aux ressources. Le couplage obtenu entre client et serveur en est ainsi affaibli.

Le panier propose des relations afin d’accéder à chaque article réservé (la relation related est souvent utilisé à des fins d’économie de ce genre) au prix total et au paiement. Un client, après avoir accédé à une ressource, navigue grâce aux relations communiquées par cette dernière aux ressources suivantes. Le code clé-en-main disponible sur GitHub couvre le paiement et la rupture du stock, afin de prolonger le sujet.

Épilogue

Implémenter REST avec Jersey résulte en un code compact, élégant, explicite et indépendant du médiatype. Le cache, la sécurité et la concurrence sont supportés dans le même esprit de simplicité. Quelques considérations sur le sujet ; comme le nom d’un auteur littéraire à succès, les URI publiques gagnent à ne pas changer. Divulger le minimum d’URI, en offrant un jeu de relations riches au client, masque la complexité du serveur ; les clients agissant en fonction de relations, modifier la logique du serveur est alors peu impactant et réduit le recours au versionning.

L’implémentation d’un client JavaScript communiquant avec le serveur développé ici, réalisée dans l’article connexe consacré au sujet, est l’occasion d’apprécier davantage les vertus de l’interface uniforme de HTTP. Le livre RESTful Web Services Cookbook est un excellent moyen de se plonger davantage encore sur la question.

• Décrire un format d’échange
• Raffiner le format d’échange
• Épilogue : un contrat d’échange côté serveur

Décrire un format d’échange

Lorsqu’une application produisant du XML n’a pas de mécanisme pour partager l’agencement de ses noeuds, il incombe à ses consommateurs de retenir une méthode pour l’exploiter au mieux. Cela peut être réalisé via une grappe d’objets équivalente à la sortie XML ; voyons comment à l’aide d’un dessert savoureux.

<recipe name="Compote de poires" type="dessert">
    <cooking duration="15">
    	<step optional="true">Réserver une gousse de vanille</step>
        <step>Éplucher et évider les poires</step>
        <step>Découper les poires en quartiers</step>
        <step>Verser les quartiers dans une casserole avec l'eau</step>
    </cooking>
    <menu>17-02-2011</menu>
    <menu>17-03-2011</menu>
</recipe>

JAXB identifie chaque noeud comme un élément doté d’attributs. Un élément est un type complexe doté d’une séquence d’éléments (toujours en premier) puis d’une liste d’attributs. Un élément peut porter une simple valeur textuelle lorsqu’il n’a pas de sous-noeuds. Un attribut ne dispose que d’une valeur textuelle. Chaque noeud XML est représenté par un élément du schéma puis, à l’aide de XJC, par un objet du même nom généré à partir de ce schéma (la génération XJC est abordée en annexe).

Voici la description du XML précédent à l’aide d’un XSD :

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
    <xsd:element name="recipe">
        <xsd:complexType>
            <xsd:sequence>
                <xsd:element name="menu" type="xsd:string" maxOccurs="unbounded" />
                <xsd:element name="cooking" type="cooking" />
            </xsd:sequence>
            <xsd:attribute name="name" type="xsd:string" />
            <xsd:attribute name="type" type="xsd:string" />
        </xsd:complexType>
    </xsd:element>
    <xsd:complexType name="cooking">
        <xsd:sequence>
            <xsd:element name="step" type="step" maxOccurs="unbounded" />
        </xsd:sequence>
        <xsd:attribute name="duration" type="xsd:int" />
    </xsd:complexType>
    <xsd:complexType name="step" mixed="true">
        <xsd:attribute name="optional" type="xsd:boolean" />
    </xsd:complexType>
</xsd:schema>

Les noeuds de ce schéma sont tous précédés de « xsd » car leur définition, sur la première ligne, nomme le XML Namespace (xmlns) ainsi. Les namespaces sont une manière de différentier les déclarations des imports d’en-tête les uns des autres, comme le ferrait un package en java.

Les variables sont typées selon la recommandation w3c. Lorsqu’une liste de types primitifs est nécessaire (noeud menu) sa déclaration n’occasionnera pas la création d’une classe, seulement d’un attribut typé. En revanche si cette liste dispose d’attributs (noeud step), il est nécessaire d’indiquer que son contenu est mixte : par défaut les éléments ont soit une valeur textuelle, soit une liste d’attributs et d’éléments, pas les deux.

Voici le code généré à partir du schéma précédent :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "recipe")
public class Recipe {
    protected List<String> menu;
    protected Cooking cooking;
    @XmlAttribute
    protected String name;
    @XmlAttribute
    protected String type;
}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "cooking")
public class Cooking {
    protected List<Step> step;
    @XmlAttribute
    protected Integer duration;
}
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "step")
public class Step {
    @XmlValue
    protected String content;
    @XmlAttribute
    protected Boolean optional;
}

Seule une classe est annotée @XmlRootElement. Elle est la seule (dans ce schéma) à pouvoir jouer le rôle de premier noeud. Une fois la grappe résultat générée, 3 lignes de code suffisent à réaliser le parsing XML :

public class JaxbTest {
    @Test
    public void should_parse_recipe() throws JAXBException {
        URL xmlUrl = Resources.getResource("recipe.xml");
        Recipe recipe = parse(xmlUrl, Recipe.class);
        assertEquals(Integer.valueOf(15), recipe.getCooking().getDuration());
    }
    private <T> T parse(URL url, Class<T> clazz) throws JAXBException {
        Unmarshaller unmarshaller = JAXBContext.newInstance(clazz).createUnmarshaller();
        return clazz.cast(unmarshaller.unmarshal(url));
    }
}

Contrairement aux bibliothèques de bas niveau, aucune conversion de type n’est nécessaire. La déclaration du type dans le schéma suffit à nous affranchir de cette responsabilité. En cas d’erreur de conversion (une chaine non convertible dans le type attendu) l’IllegalArgumentException correspondante est levée. En l’absence d’un noeud, les variables correspondantes sont null.

Raffiner le format d’échange

Une fois un data binding réussi, plusieurs opérations sont couramment nécessaires :

1. limiter un champ à un ensemble fini de valeurs ;
2. manipuler des dates plus simples que le XMLGregorianCalendar manipulé par défaut par JAXB ;
3. nommer une classe différemment de l’élément qu’elle représente ;
4. utiliser l’héritage entre éléments ;
5. annoter manuellement des classes existantes.

Limiter un champ à un ensemble fini de valeurs

Limiter l’attribut « type » de recette à « entrée, plat, dessert » peut être fait de la façon suivante :

<xsd:element name="recipe">
    <xsd:attribute name="type" type="formule" />
</xsd:element>
<xsd:simpleType name="formule">
    <xsd:restriction base="xsd:string">
        <xsd:enumeration value="entree"></xsd:enumeration>
        <xsd:enumeration value="plat"></xsd:enumeration>
        <xsd:enumeration value="dessert"></xsd:enumeration>
    </xsd:restriction>
</xsd:simpleType>

Ce qui donne, une fois généré :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "recipe")
public class Recipe {
    @XmlAttribute
    protected Formule type;
}
@XmlEnum
public enum Formule {
    @XmlEnumValue("entree")
    ENTREE("entree"),
    @XmlEnumValue("plat")
    PLAT("plat"),
    @XmlEnumValue("dessert")
    DESSERT("dessert");
    private final String value;
}

Lors du binding, s’il s’avérait que la valeur du champ ne corresponde pas à l’une de celles spécifiées ici, la valeur null serait retournée. JAXB fait le choix de positionner ses variables à null en cas de problème de valeur. Les problèmes de typage, eux, lèvent tous une exception.

Manipuler des dates simples

Pour manipuler des dates Java en lieu et place du XMLGregorianCalendar utilisé par défaut par JAXB, un convertisseur va être nécessaire. Attention, un nouveau namespace est nécessaire à sa déclaration. Il permet de redéfinir le typage de JAXB.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:jxb="http://java.sun.com/xml/ns/jaxb"
            jxb:version="2.0">
    <xsd:annotation><xsd:appinfo>
        <jxb:globalBindings>
            <jxb:javaType name="java.util.Date" xmlType="xsd:dateTime"
                          parseMethod="com.xebia.jaxb.JaxbDateConverter.parseDateTime" />
        </jxb:globalBindings>
    </xsd:appinfo></xsd:annotation>
    <xsd:element name="menu" type="xsd:dateTime" />
</xsd:schema>

Le convertisseur doit respecter la logique JAXB, si la valeur en entrée ne convient pas, aucune exception n’est levée et la valeur null est renvoyée.

public class JaxbDateConverter {
    public static Date parseDateTime(String s) {
        DateFormat formatter = new SimpleDateFormat("dd-MM-yyyy");
        try {
            return formatter.parse(s);
        } catch (ParseException e) {
            return null;
        }
    }
}

Lors de la génération, JAXB crée une classe adapter qu’il lie aux méthodes statiques du converter.

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "recipe")
public class Recipe {
    @XmlElement(type = String.class)
    @XmlJavaTypeAdapter(Adapter1.class)
    @XmlSchemaType(name = "dateTime")
    protected List<Date> menu;

Nommer une classe différemment de l’élément qu’elle représente

Pour nommer une classe différemment de l’élément qu’elle représente, il suffit d’ajouter les modifications suivantes à un schéma (attention à bien indiquer les deux namespaces) :

<xsd:element name="menu" type="xsd:dateTime" />
<xsd:annotation><xsd:appinfo>
    <jxb:class name="meal" />
</xsd:appinfo></xsd:annotation>

Utiliser l’héritage entre éléments

Utiliser l’héritage entre objet est aisé (les objets générés hériteront l’un de l’autre, bien entendu) :

<xsd:complexType name="menuxl">
    <xsd:complexContent>
        <xsd:extension base="menu" />
    </xsd:complexContent>
    <xsd:attribute name="cook" type="xsd:string" />
</xsd:complexType>

Annoter manuellement des classes existantes

Jusqu’ici nous avons fait reposer les objets d’échange sur une génération à l’aide d’un schéma. Annoter manuellement une classe en vue de lui binder du XML est également possible. Le schema correspondant peut même être généré à posteriori à partir des sources.

L’utilisation d’annotations manuelles permet d’avoir un controle plus fin sur la grappe d’objets, leur type et, pourquoi pas, d’utiliser des objets déjà utiles par ailleurs (ajouter un champ non concerné par le binding se fait à l’aide @XmlTransient).

Afin de respecter la logique JAXB, il est toutefois nécessaire de modifier les accesseurs des listes. Par convention, en l’absence de valeur, le code généré retourne des listes vides plutôt que null. JAXB, lors de la génération d’objets effectue cela via la modification des getters. Il est recommandé de faire de même.

public List<String> getMenu() {
    if (menu == null) {
        menu = new ArrayList<String>();
    }
    return menu;
}

Épilogue : un contrat d’échange côté serveur

Jusqu’ici nous avons considéré qu’aucun mécanisme décrivant l’agencement des noeuds XML n’était fourni du producteur aux consommateurs ; qu’il était résolu à postériori par ces derniers. Il est préférable, lorsque c’est possible, de les affranchir de cette contrainte en leur communiquant le schéma avec les données.

Pour ce faire, il est judicieux d’opter pour un mode de développement dirigé par le contrat. Générer les objets — côté serveur — de la couche d’échange au lieu de les annoter limite le couplage entre le schéma et son implémentation. Se restreindre aux possibilités de typage et d’agencement d’un schéma XSD garantit la compatibilité du format à tout type de consommateur (notamment autre que java). La documentation de référence Spring détaille ce propos en l’illustrant.

Annexe : outillage

Afin d’effectuer les manipulations présentées ici deux outils sont nécessaires, la dépendance maven de JAXB et le plugin de génération associé dont voici une version simple (exécutable via mvn jaxb2:xjc) :

<plugin>
    <groupId>org.codehaus.mojo</groupId>
    <artifactId>jaxb2-maven-plugin</artifactId>
    <configuration>
    	<outputDirectory>${basedir}/src/main/java</outputDirectory>
    	<schemaDirectory>${basedir}/src/main/resources/xsd</schemaDirectory>
    	<packageName>com.xebia.jaxb.generated</packageName>
    	<schemaFiles>schema.xsd</schemaFiles>
    </configuration>
</plugin>

Pour prolonger l’aventure du data binding avec JAXB, une riche documentation est disponible en ligne.

A ce stade de notre développement nous sommes déjà en mesure d’utiliser pleinement notre composant, mais nous ne pouvons pas encore en assurer sa qualité. Pour cela, il est nécessaire d’ajouter à notre composant différentes classes de test. Bien que la testabilité de frameworks d’intégration puisse parfois paraître difficile, le projet Apache Camel fournit tous les outils nécessaires permettant de répondre à ce besoin. Nous verrons donc dans cet article comment tester le composant que nous avons développé.

Pour finir, nous verrons comment intégrer notre développement à un projet Camel, ainsi que les limites de notre composant et les solutions pour résoudre ces limitations.

Tester la classe ApnsConsumer

Bien que le projet Apache Camel permette de travailler naturellement avec Spring, nous nous attarderons dans un premier temps sur les méthodes permettant de tester notre composant sur un mode standalone. Pour cela, nous étendrons la classe CamelTestSupport. Cette dernière fournit les méthodes nécessaires pour effectuer différentes assertions sur les valeurs attendues en fin de traitement, en particulier sur des endpoints de type MockEndpoint.

Nous devons tout d’abord implémenter les 2 méthodes suivantes:

Avant l’exécution de nos tests, un serveur APNS bouchonné doit être lancé. Il enverra sur le flux feedback des données factices.

L’objectif de ce test est de valider que le endpoint apns:consumer est capable de consommer les informations de test renvoyées par le flux feedback du serveur bouchonné. Le endpoint Camel mock:result nous permet de valider les assertions nécessaires sur les messages reçus par ce endpoint.

Le endpoint apns:consumer est configuré pour poller le flux feedback de l’APNS toutes les 500ms. Le test ne doit donc pas durer raisonnablement plus de 5 secondes en tenant compte du temps d’attente d’une seconde avant les assertions et du temps de démarrage du serveur bouchon APNS. Un timeout de 5 secondes est donc placé sur le test pour s’assurer que ce dernier tombe en erreur si un événement bloquant inattendu empêche le test de se terminer.

public class ApnsConsumerTest extends CamelTestSupport {
    ApnsServerStub server;
    public ApnsConsumerTest() {
    	super();
    }
    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() throws InterruptedException {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }
    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }
    /**
     * Test de l'ApnsConsumer. L'objectif est de vérifier que le flux feedback est
     * bien consommé par la route Camel. Pour cela on vérifie après consommation
     * que le endpoint MockEndpoint a bien reçu les messages.
     */
    @Test(timeout=5000)
    public void testConsumer() throws Exception {
    	byte[] deviceTokenBytes = ApnsUtils.createRandomDeviceTokenBytes();
        String deviceToken = ApnsUtils.encodeHexToken(deviceTokenBytes);
        MockEndpoint mock = getMockEndpoint("mock:result");
        mock.expectedMessageCount(1);
        mock.message(0).body().isInstanceOf(InactiveDevice.class);
        byte[] feedBackBytes = ApnsUtils.generateFeedbackBytes(deviceTokenBytes);
        server.toSend.write(feedBackBytes);
        Thread.sleep(1000);
        assertMockEndpointsSatisfied();
        InactiveDevice inactiveDevice = (InactiveDevice)mock.getExchanges().get(0).getIn().getBody();
        assertNotNull(inactiveDevice);
        assertNotNull(inactiveDevice.getDate());
        assertNotNull(inactiveDevice.getDeviceToken());
        assertEquals(deviceToken, inactiveDevice.getDeviceToken());
    }
    /**
     * Création et configuration du contexte Camel avec une configuration de test.
     * Enregistrement du composant APNS, et configuration de l'ApnsService
     */
    protected CamelContext createCamelContext() throws Exception {
        CamelContext camelContext = super.createCamelContext();
        ApnsServiceFactory apnsServiceFactory = ApnsUtils.createDefaultTestConfiguration();
        ApnsService apnsService = apnsServiceFactory.getApnsService();
        ApnsComponent apnsComponent = new ApnsComponent(apnsService);
        camelContext.addComponent("apns", apnsComponent);
        return camelContext;
    }
    /**
     * Création de la route Camel permettant de simuler la consommation du flux
     * feedback de l'APNS
     */
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from("apns:consumer?initialDelay=500&delay=500&timeUnit=MILLISECONDS")
                	.to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
                	.to("mock:result");
            }
        };
    }
}

Tester la classe ApnsProducer

De la même façon que nous nous y sommes pris pour la classe de test ApnsConsumerTest, nous allons étendre la classe CamelTestSupport pour tester notre classe ApnsProducer. L’objectif est de vérifier que le serveur bouchonné reçoit bien les messages produits.

public class ApnsProducerTest extends CamelTestSupport {
    private ApnsServerStub server;
    private String FAKE_TOKEN = "19308314834701ACD8313AEBD92AEFDE192120371FE13982392831701318B943";
    public ApnsProducerTest() {
    	super();
    }
    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }
    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }
    /**
     * Test de l'ApnsProducer. L'objectif est de vérifier que le serveur APNS a
     * bien reçu les notifications envoyées.
     * Pour cela on vérifie après production des notifications que le serveur bouchonné
     * a bien reçu les messages: On s'assure que les tableaux de bytes de la notification
     * produite et du contenu reçu par le serveur sont bien égaux.
     */
    @Test(timeout=2000)
    public void testProducer() throws Exception {
    	String message = "Hello World";
    	String messagePayload = APNS.newPayload().alertBody(message).build();
        ApnsNotification apnsNotification = new ApnsNotification(FAKE_TOKEN, messagePayload);
        server.stopAt(apnsNotification.length());
        template.sendBody("direct:test", message);
        server.messages.acquire();
        assertArrayEquals(apnsNotification.marshall(), server.received.toByteArray());
    }
    /**
     * Création et configuration du contexte Camel avec une configuration de test.
     * Enregistrement du composant APNS, et configuration de l'ApnsService
     */
    protected CamelContext createCamelContext() throws Exception {
        CamelContext camelContext = super.createCamelContext();
        ApnsServiceFactory apnsServiceFactory = ApnsUtils.createDefaultTestConfiguration();
        ApnsService apnsService = apnsServiceFactory.getApnsService();
        ApnsComponent apnsComponent = new ApnsComponent(apnsService);
        camelContext.addComponent("apns", apnsComponent);
        return camelContext;
    }
    /**
     * Création de la route Camel permettant de simuler la production de messages
     * à destination des serveurs APNS.
     */
    protected RouteBuilder createRouteBuilder() throws Exception {
        return new RouteBuilder() {
            public void configure() throws Exception {
                from("direct:test").
                setHeader(ApnsConstants.HEADER_TOKENS, constant(FAKE_TOKEN)).
                to("apns:notify");
            }
        };
    }
}

Tester l’intégration d’un composant Camel avec Spring

Les configurations Camel sont souvent déclarées par des fichiers de configuration Spring. C’est pourquoi il est nécessaire de tester l’intégration du composant dans une configuration Spring. Un bon moyen d’automatiser ce type de test est d’utiliser les classes de support JUnit fournies par Spring ( _AbstractJUnit4SpringContextTests_ ).

L’ensemble de la configuration est déclarée dans le fichier SpringApnsConsumerTest-context.xml associé au test unitaire. Les différents beans utilisés par la classe de test sont injectés via les annotations @Autowired et @EndpointInject(uri = « mock:result »).

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:camel="http://camel.apache.org/schema/spring"
       xsi:schemaLocation="
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">
	<bean id="apnsServiceFactory" class="org.apache.camel.component.apns.factory.ApnsServiceFactory">
		<property name="feedbackHost" value="localhost" />
		<property name="feedbackPort" value="7843" />
		<property name="gatewayHost" value="localhost" />
		<property name="gatewayPort" value="7654" />
		<property name="sslContext" ref="sslContext" />
	</bean>
	<!-- Déclaration de l'ApnsService, utilisé par l'ApnsComponent -->
	<bean id="apnsService" factory-bean="apnsServiceFactory" factory-method="getApnsService" />
	<bean id="sslContext" class="org.apache.camel.component.apns.util.FixedCertificates" factory-method="clientContext"/>
	<!-- Déclaration de l'ApnsComponent. Le scheme utilisé pour la création des endpoints -->
	<!-- sera l'Id utilisé pour la création du bean -->
	<bean id="apns" class="org.apache.camel.component.apns.ApnsComponent">
		<property name="apnsService" ref="apnsService" />
	</bean>
	<!-- Déclaration du context Camel, et de la route de test: 'apns-test' -->
	<!-- Les message reçus par le flux feedback seront envoyés vers le endpoint mock:result -->
	<camelContext id="camel-apns-test" xmlns="http://camel.apache.org/schema/spring">
		<route id="apns-test">
			<from uri="apns:consumer?initialDelay=500&delay=500&timeUnit=MILLISECONDS" />
			<to uri="log:org.apache.camel.component.apns?showAll=true&multiline=true" />
			<to uri="mock:result" />
		</route>
	</camelContext>
</beans>

Une fois la déclaration du composant Camel effectuée via le fichier de configuration Spring, il ne reste plus qu’à injecter les différents beans configurés dans les propriétés de la classe de test. Le contenu du test en lui-même reste identique, cependant la partie configuration a disparu ce qui rend le test plus lisible. Afin de faire disparaître du test ce qui peut encore en parasiter sa lisibilité, une classe de test parent peut être créée pour contenir les méthodes d’initialisation et d’arrêt du serveur APNS de test.

@ContextConfiguration
public class SpringApnsConsumerTest extends AbstractJUnit4SpringContextTests {
    ApnsServerStub server;
    /**
     * Injection du context Camel déclaré via Spring
     */
    @Autowired
    protected CamelContext camelContext;
    /**
     * Injection du endpoint Camel "mock:result" déclaré via Spring
     */
    @EndpointInject(uri = "mock:result")
    protected MockEndpoint mock;
    public SpringApnsConsumerTest() {
    	super();
    }
    /**
     * Démarrage du serveur bouchonné simulant l'APNS
     */
    @Before
    public void startup() throws InterruptedException {
        server = ApnsServerStub.prepareAndStartServer(FixedCertificates.TEST_GATEWAY_PORT, FixedCertificates.TEST_FEEDBACK_PORT);
    }
    /**
     * Arrêt du serveur bouchonné simulant l'APNS
     */
    @After
    public void stop() {
        server.stop();
    }
    /**
     * Test du consommateur
     */
    @Test(timeout=5000)
    public void testConsumer() throws Exception {
    	byte[] deviceTokenBytes = ApnsUtils.createRandomDeviceTokenBytes();
        String deviceToken = ApnsUtils.encodeHexToken(deviceTokenBytes);
        mock.expectedMessageCount(1);
        mock.message(0).body().isInstanceOf(InactiveDevice.class);
        byte[] feedBackBytes = ApnsUtils.generateFeedbackBytes(deviceTokenBytes);
        server.toSend.write(feedBackBytes);
        Thread.sleep(1000);
        mock.assertIsSatisfied();
        InactiveDevice inactiveDevice = (InactiveDevice)mock.getExchanges().get(0).getIn().getBody();
        Assert.assertNotNull(inactiveDevice);
        Assert.assertNotNull(inactiveDevice.getDate());
        Assert.assertNotNull(inactiveDevice.getDeviceToken());
        Assert.assertEquals(deviceToken, inactiveDevice.getDeviceToken());
    }
}

Limitations du composant actuel

Dans un soucis de simplicité, le composant présenté est limité fonctionnellement et ne propose qu’un ensemble réduit de fonctionnalités. L’implémentation proposée dans ce billet nous oblige à déclarer les tokens à notifier directement au niveau de la route. Cependant une implémentation plus complète pourrait permettre d’exploiter des en-têtes par exemple pour rendre la sélection de token à notifier plus dynamique.

Heureusement, la richesse du framework Apache Camel nous permet de passer outre cette restriction et d’obtenir l’aspect dynamique souhaité en utilisant le pattern Recipient List, qui permet par exemple l’extraction des URIs de destination depuis un en-tête de message produit au préalable.

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        from("direct:a").recipientList(
        header("recipientListHeader").tokenize(","));
    }
};

Dans cet exemple, l’en-tête recipientListHeader contiendrait les différentes URIs séparées par des virgules.

Utilisation du composant dans un projet

Pour utiliser le composant développé dans cette série d’articles, il suffit de l’importer en tant que dépendance Maven dans votre projet Camel et de déclarer le repository qui permettra de le charger à défaut de l’avoir déjà dans son répository local.

Ce qui donne les lignes suivantes à ajouter dans le pom de votre projet:

• La dépendance Maven:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-apns</artifactId>
    <version>2.4.0</version>
</dependency>

• Le repository Maven qui met à disposition le composant:

<repositories>
    <repository>
        <id>camel-apns.repo-release</id>
        <url>http://camel-apns.googlecode.com/svn/maven/public/repository/release/</url>
    </repository>
</repositories>

Exemples d’utilisation

Afin de donner une vision synthétique de l’usage de notre composant, voici un condensé de quelques exemples d’utilisation:

• Consommation du flux feedback avec une configuration Java

      from("apns:consumer")
            .to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
            .to("mock:result");

• Envoi de notifications avec une configuration Java

      from("direct:test")
            .setHeader(ApnsConstants.HEADER_TOKENS, constant(FAKE_TOKEN))
            to("apns:notify");

• Envoi d’une notification avec une configuration Spring

<camelContext id="camel-apns-test" xmlns="http://camel.apache.org/schema/spring">
	<route id="apns-test">
		<from uri="apns:consumer" />
		<to uri="log:org.apache.camel.component.apns?showAll=true&multiline=true" />
		<to uri="mock:result" />
	</route>
</camelContext>

Conclusion

Nous avons vu dans cet article comment créer et tester un composant Camel qui communique avec les serveurs de notifications d’Apple. Les API du framework ont été pensées pour faciliter le développement de nouveaux composants, et vous permettront d’implémenter et de tester facilement les composants dont vous avez besoin. Vous pouvez consulter le code source du composant camel-apns présenté dans cette série d’article sur sa page Google Code.

Liens utiles:

Le site google code du composant ‘camel-apns’ présenté dans le billet:

• http://code.google.com/p/camel-apns

D’autres liens utiles sur le développement de composants Camel:

• Créer des tests unitaires Apache Camel
• Tester un composant Apache Camel

Précédentes parties de l’article:

• Créer un composant Apache Camel de connexion à l’APNS – 1 sur 3
• Créer un composant Apache Camel de connexion à l’APNS – 2 sur 3

Implémentation du composant

Les quatre interfaces suivantes doivent être implémentées pour développer un composant Camel permettant à la fois de consommer et produire des messages :

La classe ApnsService

Pour communiquer avec les serveurs Apple, nous devons instancier un objet ApnsService. Le framework java-apns fournit pour cela la classe ApnsServiceBuilder. Celle-ci permet de construire facilement un objet ApnsService en spécifiant au builder la configuration souhaitée.

Le builder est obtenu grâce à la classe utilitaire Apns :

        ApnsServiceBuilder builder = APNS.newService();

Ensuite, il suffit d’appeler les différentes méthodes de configuration du builder. Dans le cadre d’une configuration simple, le code source suivant est suffisant :

// Instanciation du builder
ApnsServiceBuilder builder = APNS.newService();
InputStream certificateInputStream = null;
try {
    // Ouverture de l'inputStream correspondant au certificat
	certificateInputStream = ResourceUtils.getInputStream("certificate_classpath");
	// Configuration du certificat utilisé pour communiquer avec l'APNS
	builder.withCert(certificateInputStream, "certificate_password")
}
finally {
	// Fermeture de l'inputStream correspondant au certificat
	ResourceUtils.close(certificateInputStream);
}
// Configuration des URLs par défaut de production vers les serveurs APNS
builder.withProductionDestination();
// Configuration d'un pool de 5 connexions vers les serveurs APNS
builder.asPool(5);
// Configuration d'une politique de reconnexion uniquement lorsqu'une connexion vers les serveurs APNS est fermée
builder.withReconnectPolicy(ReconnectPolicy.Provided.NEVER);
// Obtention de l'instance configurée
ApnsService apnsService = builder.build();

Note : Un exemple de configuration plus complet de l’objet ApnsService peut être trouvé dans le code source du composant camel-apns.

Afin d’intégrer de façon efficace notre composant avec Spring, la classe ApnsServiceBuilder se révèle être un bon point de départ pour écrire une factory permettant de construire un objet ApnsService via Spring.

La classe ApnsComponent

L’interface Component correspond à l’unité de base définissant un composant Camel. Ce dernier est associé au scheme d’une URI lorsqu’il est ajouté à un contexte d’exécution.

Une implémentation par défaut de cette interface est fournie (en l’occurrence la classe DefaultComponent), ce qui permet de se focaliser sur les fonctionnalités de notre composant. Un composant Camel a pour rôle de créer les endpoints relatifs aux URI définies dans le contexte Camel. Cette tâche est réalisée par la méthode createEndpoint.

Chaque endpoint créé à partir d’un même ApnsComponent utilisera une unique configuration pour échanger avec l’APNS. C’est pourquoi le service d’accès à l’APNS sera injecté au niveau de l’objet ApnsComponent.

Le bean apnsService peut être setté par le constructeur ou bien par un setter pour faciliter l’intégration avec Spring.

public class ApnsComponent extends DefaultComponent {
	private ApnsService apnsService;
	public ApnsComponent() {
		super();
	}
	public ApnsComponent(ApnsService apnsService) {
		super();
		AssertUtils.notNull(apnsService, "apnsService is mandatory");
		this.apnsService = apnsService;
	}
	public ApnsComponent(CamelContext context) {
		super(context);
	}
	public ApnsService getApnsService() {
		return apnsService;
	}
	@SuppressWarnings("unchecked")
	protected Endpoint createEndpoint(String uri, String remaining, Map parameters) throws Exception {
		ApnsEndpoint endpoint = new ApnsEndpoint(uri, this);
		setProperties(endpoint, parameters);
		return endpoint;
	}
    /**
     * L'objet ApnsService peut être setté s'il le constructeur vide a été appelé pour instancier un objet ApnsComponent
     */
	public void setApnsService(ApnsService apnsService) {
		if (this.apnsService != null) {
			throw new IllegalArgumentException("apnsService already setted");
		}
		this.apnsService = apnsService;
	}
}

La classe ApnsEndpoint

La classe ApnsEndpoint permet de gérer la création des objets Consumer et Producer définis dans les routes Camel. Dans notre cas, nous étendrons la classe ScheduledPollEndpoint. Elle permet d’implémenter un endpoint qui saura créer des objets Consumer dont le déclenchement s’effectuera à intervalle régulier.

C’est la classe ApnsEndpoint qui a la charge de gérer les paramètres passés dans l’URI. Ainsi, les tokens passés en paramètres de l’URI d’un objet ApnsEndpoint seront injectés automatiquement via les setters correspondant aux paramètres renseignés. Si un paramètre ne correspond pas à un setter déclaré, une exception sera alors lancée.

Afin de faciliter le travail de configuration des paramètres spécifiques au travail de polling, c’est la classe ScheduledPollEndpoint qui lira automatiquement les paramètres de déclenchement renseignés sur l’URI. L’ApnsEndpoint aura donc toutes les informations nécessaires pour configurer les paramètres de déclenchement de l’objet ApnsConsumer.

Dans le cas de l’exécution de tests, les paramètres de déclenchement de la consommation de messages en provenance de l’APNS peuvent être configurés de la façon suivante :

from("apns:consumer?initialDelay=500&delay=500&timeUnit=MILLISECONDS")
	.to("log:com.apache.camel.component.apns?showAll=true&multiline=true")
	.to("mock:result");

L’implémentation de la classe ApnsEndpoint donnera le code source suivant :

public class ApnsEndpoint extends ScheduledPollEndpoint {
	@SuppressWarnings("unused")
	private static final Log LOG = LogFactory.getLog(ApnsEndpoint.class);
	private CopyOnWriteArraySet<DefaultConsumer> consumers = new CopyOnWriteArraySet<DefaultConsumer>();
	private String tokens;
	public ApnsEndpoint(String uri, ApnsComponent component) {
		super(uri, component);
	}
	public String getTokens() {
		return tokens;
	}
	public void setTokens(String tokens) {
		this.tokens = tokens;
	}
	private ApnsComponent getApnsComponent() {
		return (ApnsComponent)getComponent();
	}
    /**
     * On obtient une instance de la clase ApnsService depuis l'object ApnsComponant
     */
	public ApnsService getApnsService() {
		return getApnsComponent().getApnsService();
	}
    /**
      * Indique que le endpoint n'est instancié qu'une seule fois par le contexte Camel
      */
	public boolean isSingleton() {
		return true;
	}
    /**
     * Permet d'obtenir la liste des consumers
     */
	protected Set<DefaultConsumer> getConsumers() {
		return consumers;
	}
    /**
     * Permet de créer un consumer
     */
	public Consumer createConsumer(Processor processor) throws Exception {
		ApnsConsumer apnsConsumer = new ApnsConsumer(this, processor);
		configureConsumer(apnsConsumer);
		return apnsConsumer;
	}
	/**
	 * Permet de créer un producer
	 */
	public Producer createProducer() throws Exception {
		return new ApnsProducer(this);
	}
}

La classe ApnsProducer

La classe ApnsProducer correspond à la classe qui permet d’envoyer des notifications aux terminaux mobiles Apple via les serveurs APNS. La classe abstraite DefaultProducer sera étendue pour fournir un support de base à notre implémentation.

Seule la méthode process reste ainsi à renseigner. Il suffira d’y implémenter l’envoi de la notification à l’APNS comme suit :

public class ApnsProducer extends DefaultProducer {
	private static final transient Log LOG = LogFactory.getLog(ApnsProducer.class);
	private ApnsEndpoint endpoint;
	private List<String> tokenList;
	public ApnsProducer(ApnsEndpoint endpoint) {
		super(endpoint);
		this.endpoint = endpoint;
		configureTokens(apnsEndpoint);
	}
    /**
     * La méthode configureTokens permet d'extraire la liste de tokens destinataires
     * des notifications envoyées au endpoint.
     */
	private void configureTokens(ApnsEndpoint apnsEndpoint) {
		if (StringUtils.isNotEmpty(apnsEndpoint.getTokens())) {
			try {
				this.tokenList = extractTokensFromString(apnsEndpoint.getTokens());
			} catch (CamelException e) {
				throw new IllegalArgumentException(e);
			}
		}
	}
	/**
	 * Méthode appelée par le producer pour traiter les échanges Camel
	 */
	public void process(Exchange exchange) throws Exception {
		notify(exchange);
	}
	/**
	 * La méthode notify  est appelée pour envoyer une notification aux serveurs APNS.
	 */
	private void notify(Exchange exchange) throws ApnsException, CamelException {
		String payload = exchange.getIn().getBody(String.class);
                // Une copie de la liste des tokens à notifier est passée en paramètre,
                // ainsi que le payload du message
		endpoint.getApnsService().push(new ArrayList<String>(tokenList), payload);
	}
	/**
	 * On extrait une liste de tokens à partir d'une chaîne de caractères contenant
	 * des tokens séparés par un point virgule.
	 */
	private List<String> extractTokensFromString(String tokensStr) throws CamelException {
		tokensStr = StringUtils.trim(tokensStr);
		if (tokensStr.isEmpty()) {
			throw new CamelException("No token specified");
		}
		String[] tokenArray = tokensStr.split(";");
		int tokenArrayLength = tokenArray.length;
		for (String token : tokenArray) {
			token = token.trim();
			int tokenLength = token.length();
			// La taille d'un token est limitée à 64 caractères
			if (tokenLength != 64) {
				throw new CamelException("Token has wrong size['" + tokenLength + "']: " + token);
			}
		}
		List<String> tokens = Arrays.asList(tokenArray);
		return tokens;
	}
}

Une fois la notification envoyée aux serveurs APNS, le terminal Apple recevra la notification et l’affichera comme suit dans le cas d’une notification texte:

  

La classe ApnsConsumer

La classe ApnsConsumer a pour objectif de nous permettre de consommer le flux feedback renvoyé par les serveurs APNS, permettant de connaître les terminaux mobiles Apple pour lesquels il n’est plus nécessaire d’envoyer de notifications (Par exemple, lorsque l’application a été désintallée).

Comme vu précédemment, la stratégie de consommation peut suivre un pattern de type Event Driven Consumer ou bien de Polling Consumer. Ici, nous choisirons le pattern Event Driven Consumer, et nous étendrons la classe ScheduledPollConsumer qui prend en charge toute la complexité de la gestion de consommation des messages et nous laisse nous concentrer sur le principal, c’est à dire, fournir les messages à consommer par nos routes de traitement.

Pour cela, il suffit d’implémenter la méthode poll qui permet d’interroger le service feedback d’Apple selon le timing d’interrogation configuré par l’URI.

C’est la classe ApnsEndpoint, qui au moment de la création de l’objet ApnsConsumer, configurera les paramétrages de polling à partir des paramètres récupérés via l’URI.

La méthode doStart aura pour rôle de vérifier qu’un seul objet ApnsConsumer est créé afin de ne pas consommer en double les messages d’une même configuration de l’ApnsService.

La méthode poll est implémentée ici de façon à récupérer les informations sur les appareils pour lesquels il ne faut plus envoyer de notifications. Pour cela, nous récupérons dans un premier temps une liste d’objets InactiveDevice renvoyés par le flux feedback de l’APNS, puis nous itérons sur cette liste pour les faire traiter par le processor Camel, qui n’est autre que la route de traitement Camel.

public class ApnsConsumer extends ScheduledPollConsumer {
	private static final int DEFAULT_CONSUME_INITIAL_DELAY = 10;
	private static final int DEFAULT_CONSUME_DELAY = 3600;
	private static final TimeUnit DEFAULT_CONSUME_TIME_UNIT = TimeUnit.SECONDS;
	private static final boolean DEFAULT_APNS_FIXED_DELAY = true;
	/**
	 * La configuration par défaut des paramètres de polling est fait lors de la
	 * construction de l'objet. Ces valeurs pourront être écrasées par des valeurs
	 * configurées via l'URI.
	 */
	public ApnsConsumer(ApnsEndpoint apnsEndpoint, Processor processor) {
		super(apnsEndpoint, processor);
		setInitialDelay(DEFAULT_CONSUME_INITIAL_DELAY);
		setDelay(DEFAULT_CONSUME_DELAY);
		setTimeUnit(DEFAULT_CONSUME_TIME_UNIT);
		setUseFixedDelay(DEFAULT_APNS_FIXED_DELAY);
	}
	/**
	 * Chaque élément de cette liste obtenue par l'appel de la méthode  getInactiveDevices()
	 * sera passé à la route Camel via l'appel de la méthode getProcessor().process(e)
	 */
	protected void poll() throws Exception {
		List<InactiveDevice> inactiveDeviceList = getInactiveDevices();
		Iterator<InactiveDevice> it = inactiveDeviceList.iterator();
		while(it.hasNext()) {
			InactiveDevice inactiveDevice = it.next();
			Exchange e = getEndpoint().createExchange();
			e.getIn().setBody(inactiveDevice);
			// On donne chaque élément de la liste de terminaux inactifs
			// reçu sur le flux feedback pour qu'il soit traité par la route associée
			getProcessor().process(e);
		}
	}
	/**
	 * La méthode getInactiveDevices() permet d'obtenir depuis le flux feedback une
	 * liste d'objects InactiveDevice.
	 */
	private List<InactiveDevice> getInactiveDevices() {
		ApnsEndpoint ae = (ApnsEndpoint)getEndpoint();
		Map<String, Date> inactiveDeviceMap = ae.getApnsService().getInactiveDevices();
		List<InactiveDevice> inactiveDeviceList = new ArrayList<InactiveDevice>();
		for (Entry<String, Date> inactiveDeviceEntry : inactiveDeviceMap.entrySet()) {
			String deviceToken = inactiveDeviceEntry.getKey();
			Date date = inactiveDeviceEntry.getValue();
			InactiveDevice inactiveDevice = new InactiveDevice(deviceToken, date);
			inactiveDeviceList.add(inactiveDevice);
		}
		return inactiveDeviceList;
	}
    @Override
	public ApnsEndpoint getEndpoint() {
		return (ApnsEndpoint)super.getEndpoint();
	}
	/**
	 * La consommation du flux feedback doit être faite par un unique consumer.
	 * La méthode doStart permet de s'enassurer lors du démarrage.
	 * Si un autre consumer est déjà déclaré, alors une exception sera lancée.
	 */
    @Override
    protected void doStart() throws Exception {
        // only add as consumer if not already registered
        if (!getEndpoint().getConsumers().contains(this)) {
            if (!getEndpoint().getConsumers().isEmpty()) {
                throw new IllegalStateException("Endpoint " + getEndpoint().getEndpointUri() + " only allows 1 active consumer but you attempted to start a 2nd consumer.");
            }
            getEndpoint().getConsumers().add(this);
        }
        super.doStart();
    }
    @Override
    protected void doStop() throws Exception {
        super.doStop();
        getEndpoint().getConsumers().remove(this);
    }
}

Conclusion

Nous avons vu dans cette seconde partie comment implémenter les classes nécessaires au développement d’un composant Apache Camel. Nous verrons dans une dernière partie comment mettre en place différentes stratégies de test pour valider notre composant.

Liens utiles

• http://camel.apache.org/writing-components.html
• Création d’un composant Camel pour communiquer avec Amazon SQS
• Apple Push Notification Service par Apple
• Provider Communication with Apple Push Notification Service par Apple

Le site google code du composant ‘camel-apns’ présenté dans l’article :

• http://code.google.com/p/camel-apns

Parties suivantes et précédentes de l’article :

• Créer un composant Apache Camel de connexion à l’APNS – 1 sur 3
• Créer un composant Apache Camel de connexion à l’APNS – 3 sur 3

Apache Camel utilise la notion d’URIs, ce qui permet de travailler facilement avec différents types de transport ou modèles d’échange de messages, tels que HTTP ou JMS. De la même manière, Apache Camel est capable de travailler avec différents formats de données (Csv, Xml, Json, …).

L’utilisation des composants fournis out of the box permet de travailler avec de nombreux protocoles et formats de données. Mais qu’en est-il lorsqu’un connecteur vient à manquer?

Pour répondre à cette question, le projet Apache Camel propose une API complète permettant d’implémenter soi-même des composants adaptés à son besoin.

Objectif

L’objectif de cet article est de présenter comment initier le développement d’un composant Apache Camel.

Pour cela, nous mettrons en place un composant qui permettra de dialoguer avec l’Apple Push Notification Service, dans le but d’envoyer des notifications aux différents terminaux Apple (iPad, iPhone, iPod Touch).

Le composant proposera à la fois des endpoints de type producer et de type consumer qui permettrons respectivement d’envoyer des notifications et de lire un flux feedback d’informations en provenance de l’APNS.

En pré-requis, un ensemble de endpoints devra utiliser une même instance de la classe ApnsService proposée par la librairie java-apns, qui permet de dialoguer avec les serveurs d’Apple. La firme à la pomme préconise en effet de créer un nombre limité de connexions, et de réutiliser celles-ci pour communiquer avec ses serveurs. Nous utiliserons également le scheme apns pour déclarer les URIs qui représenteront les endpoints gérés par nos composants.

Présentation de l’APNS

L’Apple Push Notification Service est disponible pour les applications destinées aux iPhones, iPads et iPods touch. Il permet d’envoyer des notifications de 3 types : texte, image ou badge.

Pour envoyer une notification, un provider (une application serveur en général) doit en premier lieu envoyer la notification à l’Apple Push Notification Service qui se chargera à son tour de diffuser la notification aux terminaux concernés.

La notification est composée d’un token (identifiant unique d’un terminal) et d’un payload (contenu de la notification).

L’APNS propose en complément de l’envoi de notifications, un flux feedback d’informations permettant de connaître la liste des terminaux pour lesquels les notifications n’ont pu être délivrées de façon répétée (généralement, lorsque l’application a été désinstallée).

Pour qu’une application iOS soit en mesure de recevoir des notifications, elle doit en premier lieu fournir à l’application serveur (celle qui va envoyer les notifications aux serveurs Apple) toutes les informations nécessaires notamment son token d’identification. Cette opération peut-être réalisée, par exemple, via un simple appel HTTP.

API Java de connexion à l’APNS

De nombreux projets permettent de dialoguer avec l’APNS via différents langages de programmation. Actuellement deux implémentations existent pour le langage Java :

• java-apns sur GitHub, et
• javapns sur Google Code.

Historiquement, l’implémentation javapns est apparue avant java-apns. Cependant nous choisirons d’utiliser la librairie java-apns qui a pour avantage de proposer des fonctionnalités complètes (gestion de pool de connections, capacité de reconnexion, …), ainsi qu’une API élégante et différentes facilités d’écriture de tests unitaires.

Les endpoints Camel

Le développement d’un endpoint Apache Camel implique d’implémenter une ou plusieurs des méthodes suivantes selon les besoins :

L’Event Driven Consumer

Ce modèle événementiel de consommation des messages correspond au modèle de consommation par défaut des messages par les composants Camel.

Le Polling Consumer

Le polling consumer propose 3 types de méthodes:

Le composant camel-jms implémente cette notion de polling-consumer pour s’intégrer à Apache Camel.

Générer un squelette de composant

Partir de zéro pourrait s’avérer compliqué. Heureusement le projet Apache Camel met à disposition l’archétype Maven: camel-artefact-component.

mvn archetype:create
-DarchetypeGroupId=org.apache.camel.archetypes
-DarchetypeArtifactId=camel-archetype-component
-DarchetypeVersion=2.3.0
-DgroupId=org.apache.camel
-DartifactId=camel-apns

L’exécution de la ligne de commande précédente va créer un squelette de composant sur lequel s’appuyer pour développer notre composant:

L’archétype va générer la structure nécessaire au développement du composant Camel. Cependant il sera nécessaire de personnaliser le composant nouvellement créé pour qu’il corresponde au nommage souhaité :

• ‘META-INF/services/<PACKAGE_NAME>/direct’ devra être renommé selon le scheme de l’URI de votre composant (Dans notre cas: ‘apns’).
• Les différentes classes générées seront préfixées par ‘Apns’ plutôt que ‘Direct’.

Il est possible de supprimer les classes qui ne seraient pas utilisées dans le cas où le composant serait uniquement destiné à consommer des messages ou à bien en produire.

Après renommage, le résultat obtenu doit être le suivant :

Importer son composant dans Eclipse

Pour cela, il est possible d’utiliser la commande suivante:

mvn eclipse:eclipse

Le fichier pom.xml

Il est conseillé d’hériter du projet parent camel-parent:

<parent>
	<groupId>org.apache.camel</groupId>
	<artifactId>camel-parent</artifactId>
	<version>2.4.0</version>
</parent>

Le composant camel-parent déclare en effet un certain nombre de dépendances nécessaires, ainsi que le type bundle qui permet d’OSGifier son composant. Ceci permettra aux utilisateurs/développeurs de le déployer dans un conteneur OSGi, tel qu’Apache ServiceMix.

Nous allons donc déclarer le packaging du composant, ainsi que différentes propriétés nécessaires à l’OSGificiation comme suit:

<packaging>bundle</packaging>
...
<properties>
	...
	<!-- OSGi bundles properties -->
	<camel.osgi.import.pkg><strong></camel.osgi.import.pkg>
	<camel.osgi.private.pkg>!</strong></camel.osgi.private.pkg>
	<camel.osgi.export>${camel.osgi.export.pkg}*;version=${camel.osgi.export.version}</camel.osgi.export>
	<camel.osgi.export.version>${project.version}</camel.osgi.export.version>
	<camel.osgi.import>${camel.osgi.import.pkg}</camel.osgi.import>
	<camel.osgi.symbolic.name>${groupId}.${artifactId}</camel.osgi.symbolic.name>
</properties>

Il est également nécessaire de déclarer les dépendances Camel dont nous aurons besoin, ainsi que les dépendances nécessaires à l’implémentation du composant:

<dependencies>
	...
	<!-- Camel -->
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-core</artifactId>
		<version>${camel.version}</version>
	</dependency>
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-spring</artifactId>
		<version>${camel.version}</version>
	</dependency>
	<dependency>
		<groupId>org.apache.camel</groupId>
		<artifactId>camel-test</artifactId>
		<version>${camel.version}</version>
		<scope>test</scope>
	</dependency>
	...
	<!-- APNS -->
	<dependency>
		<groupId>com.notnoop.apns</groupId>
		<artifactId>apns</artifactId>
		<version>${apns.version}</version>
		<exclusions>
			<exclusion>
				<groupId>ch.qos.logback</groupId>
				<artifactId>logback-classic</artifactId>
			</exclusion>
		</exclusions>
	</dependency>
	...
</dependencies>

Le projet Apache Camel propose le plugin camel-maven-plugin que nous allons déclarer dans notre fichier pom. Celui-ci permet de lancer en ligne de commande une instance standalone d’Apache Camel et de démarrer les routes qui sont déclarées dans le classpath via le fichier Spring suivant: ‘META-INF/spring/camel-context.xml’.

<!-- allows the route to be ran via 'mvn camel:run' -->
<plugin>
	<groupId>org.apache.camel</groupId>
	<artifactId>camel-maven-plugin</artifactId>
	<version>${camel.version}</version>
</plugin>

Plusieurs entrées repository et pluginReposity doivent également être déclarées dans le pom afin que Maven puisse importer différentes dépendances et plugins nécessaires à notre projet:

<repositories>
	<repository>
		<id>open.iona.m2</id>
		<name>IONA Open Source Community Release Repository</name>
		<url>http://repo.open.iona.com/maven2</url>
		<snapshots>
			<enabled>false</enabled>
		</snapshots>
		<releases>
			<enabled>true</enabled>
		</releases>
	</repository>
	<repository>
		<id>open.iona.m2-snapshot</id>
		<name>IONA Open Source Community Snapshot Repository</name>
		<url>http://repo.open.iona.com/maven2-snapshot</url>
		<snapshots>
			<enabled>true</enabled>
		</snapshots>
		<releases>
			<enabled>false</enabled>
		</releases>
	</repository>
	<!-- java-apns repository -->
	<repository>
		<id>notnoop-repos</id>
		<url>http://notnoop.github.com/m2-repo</url>
	</repository>
	...
	<repository>
		<id>apache.incubating.releases</id>
		<name>Apache Incubating Release Distribution Repository</name>
		<url>http://people.apache.org/repo/m2-incubating-repository</url>
	</repository>
</repositories>
<pluginRepositories>
	<pluginRepository>
		<id>open.iona.m2</id>
		<name>IONA Open Source Community Release Repository</name>
		<url>http://repo.open.iona.com/maven2</url>
		<snapshots>
			<enabled>false</enabled>
		</snapshots>
		<releases>
			<enabled>true</enabled>
		</releases>
	</pluginRepository>
	<pluginRepository>
		<id>open.iona.m2-snapshot</id>
		<name>IONA Open Source Community Snapshot Repository</name>
		<url>http://repo.open.iona.com/maven2-snapshot</url>
		<snapshots>
			<enabled>true</enabled>
		</snapshots>
		<releases>
			<enabled>false</enabled>
		</releases>
	</pluginRepository>
	<pluginRepository>
		<id>maven-repository.dev.java.net</id>
		<name>Java.net Maven 2 Repository</name>
		<url>http://download.java.net/maven/2</url>
	</pluginRepository>
</pluginRepositories>

Conclusion

Nous avons vu dans cette première partie comment initier le développement d’un composant Camel à l’aide de l’archétype Maven camel-archetype-component.

Dans un prochain billet, nous verrons comment implémenter les différentes classes d’un composant Camel. Puis nous conclurons dans une troisième et dernière partie, par la présentation des méthodes permettant de tester notre composant afin de fournir un livrable de qualité.

Liens utiles:

• Le site du projet Apache Camel
• http://camel.apache.org/creating-a-new-camel-component.html

Le site google code du composant camel-apns présenté dans cet article:

• http://code.google.com/p/camel-apns

Parties suivantes de l’article :

• Créer un composant Apache Camel de connexion à l’APNS – 2 sur 3
• Créer un composant Apache Camel de connexion à l’APNS – 3 sur 3

Dans la suite de ce billet, nous allons essayer d’analyser cette tendance émergente en revenant brièvement sur :

• Ce qu’est un ESB et les besoins des systèmes en terme d’intégration.
• Les plates-formes de cloud computing et leurs différents modèles.

Les ESB

Les tentatives pour couvrir la définition et l’utilisation des ESB ont fait couler beaucoup d’encre. Revenir brièvement sur le sujet s’avère donc un exercice très difficile. Néanmoins, on pourrait le synthétiser de la sorte (pour plus d’approfondissement, n’hésitez pas à consulter notre livre blanc sur le sujet) :

Un ESB est une plate-forme d’intégration basée sur des standards ouverts. Elle combine les fonctions d’échange de messages, de transformation, de routage et d’exposition de services, afin de permettre de relier efficacement et de coordonner les différentes composantes d’un système d’information étendu. À bien des égards, un ESB pourrait être un point de départ pour l’émergence d’une SOA orientée événement ou « Event-Driven SOA ».

Quelles motivations pourraient pousser une telle plate-forme à migrer vers les nuages ? Essayons de les appréhender en s’intéressant de plus près à ce nouvel environnement d’exécution.

Le cloud computing

Wikipedia définit le cloud computing, selon le livre blanc de notre cher SYNTEC, comme un concept se déclinant sous trois formes :

• IaaS : infrastructure as a Service. C’est le niveau le plus bas. Le fournisseur assure dans ce cas les infrastructures matérielles nécessaires à la demande et selon les besoins de scalabilité et de stockage de l’application. Le client doit prendre en charge tous les aspects OS, pile logicielle et configuration pour tirer profit de l’élasticité des infrastructures fournies. On pourra citer comme exemple Amazon EC2.
• PaaS : plate-forme as a Service, niveau intermédiaire. Le fournisseur met à disposition une pile logicielle spécifique à ses infrastructures matérielles. Il assure derrière la disponibilité de votre application en lui allouant dynamiquement les ressources nécessaires selon les variations de sa charge. Un des exemples les plus célèbres est Google App Engine
• SaaS : Software as a Service, niveau le plus haut du concept. Le client consomme le logiciel hébergé par la plate-forme sur une base de paiement par utilisation (pay per use). SalesForce a été un des pionniers de ce type de service.

Notons que le principe du « pay per use » s’applique aux différentes déclinaisons citées ci-dessus. Il représente un des avantages principaux du cloud computing. Il permet la rationalisation des coûts et l’élimination du gaspillage en exploitation, licences, …

Et comme il y a toujours un « Mais », celui du cloud computing a toujours été la sécurité des données et dans une moindre mesure le lock-in par rapport aux fournisseurs. Ce qui a donné naissance à une nouvelle variante, les clouds privés. Les entreprises désireuses de tirer profit du concept et ne voulant pas confier leurs données stratégiques à Amazon, Google et consorts, ont opté pour cette alternative. Elles gardent ainsi la main sur l’exploitation et la gouvernance de leurs infrastructures existantes tout en les mutualisant entre leurs différentes filiales.

Les premières applications à avoir été mises dans les nuages ont été les commodités telles que les solutions de stockage, les CRM, quelques modules d’ERP (par exemple l’offre Business ByDesign de SAP)…

Quels arguments pour les ESB dans les nuages ?

À la suite de ce bref tour d’horizon, deux arguments semblent se dégager en faveur d’un déploiement des ESB dans le cloud :

1. Les ESB, de par leur adoption de standards ouverts, pourraient être un jour considérés comme des commodités, ce qui en fait un bon candidat pour le cloud. Cependant, les tentatives de standardisation, telles que JBI, n’ont à ce jour pas rassemblé un nombre critique d’acteurs et l’offre actuelle du marché reste composée de solutions hétérogènes, adoptant des architectures différentes.
2. Un déploiement dans les nuages permettrait une intégration pervasive inter-SI, rendant les échanges entre les départements d’une même entreprise plus directs. Cela permet aussi de faciliter l’intégration des éventuelles nouvelles applications en mode SaaS avec le reste du parc applicatif.

Par ailleurs, porter son bus dans les nuages induira des défis différents selon si l’on choisit un cloud privé ou public. Dans le premier cas, ils seront plutôt du côté de l’exploitation traditionnellement orientée vers la gestion des bases de données, des serveurs d’applications et des serveurs web et il faudra donc se munir d’un framework approprié pour la gestion d’ESB dans son cloud privé tel que Stratos. Dans le deuxième cas, ils seront plus nombreux. On citera principalement, la sécurité, la gouvernance et l’ouverture des firewall afin de pouvoir communiquer avec une plate-forme publique externe.

Perspectives

Les ESB dans les nuages ne sont qu’à leur début et la pertinence de ce portage est loin encore de faire l’unanimité. Certaines parties affirment même que les ESB n’ont pas leur place dans le cloud. Le débat promet d’être intéressant et animé.

Références

• Le système d’information durable
• Entreprise service bus
• ESBs in the cloud: Tricky in the early going
• What’s Next for the ESB? End of the Line, or Cloud Broker
• RunMyProcess

Ce modèle a été développé par Léonard Richardson. Léonard Richardson est, entre autres, co-auteur du livre « Restful Web Service » publié chez O’Reilly.
Martin Fowler a récemment publié un papier à propos du Modèle de Maturité de Richardson intitulé « Richardson Maturity Model: steps toward the glory of REST ». Dans ce papier, Martin Fowler déroule et commente le Richardson Maturity Model au travers d’un cas d’utilisation simple (réserver un rendez-vous chez le médecin).

Ce billet présente le Richardson Maturity Model en s’appuyant en grande partie sur le papier de Martin Fowler. Au programme :

• Le niveau 0 : Le RPC sur HTTP en POX (Plain Old XML).
• Le niveau 1 : L’utilisation de ressources différentiées.
• Le niveau 2 : L’utilisation des verbes et des codes retours HTTP.
• Le niveau 3 : L’utilisation des contrôles hypermédia.

Le niveau 0 : Le RPC sur HTTP en POX

A ce niveau, qui constitue le point de départ du modèle, on ne peut pas vraiment parler de REST : on se contente d’utiliser HTTP comme système de transport pour interagir à distance avec un « service ».
Toutes les requêtes sont envoyées vers le même endpoint (la même URI) : /appointmentService. Elles sont complètement décrites dans le flux XML envoyé. Dans l’exemple proposé par Martin Fowler, la réservation se fait de la façon suivante :

Une première requête est envoyée pour obtenir les créneaux disponibles à une date donnée :

POST /appointmentService HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04" doctor = "mjones"/>
Le serveur retourne une liste de créneaux :
HTTP/1.1 200 OK
[various headers]
<openSlotList>
  <slot start = "1400" end = "1450">
    <doctor id = "mjones"/>
  </slot>
  <slot start = "1600" end = "1650">
    <doctor id = "mjones"/>
  </slot>
</openSlotList>

Une deuxième requête est envoyée (sur le même endpoint) pour réserver un des créneaux de la liste :

POST /appointmentService HTTP/1.1
[various other headers]
<appointmentRequest>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointmentRequest>

Si la demande aboutit, le serveur retourne un rendez-vous :

HTTP/1.1 200 OK
[various headers]
<appointment>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

Si la demande échoue, le serveur retourne un message d’erreur :

HTTP/1.1 200 OK
[various headers]
<appointmentRequestFailure>
  <slot doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <reason>Slot not available</reason>
</appointmentRequestFailure>

Vous noterez l’incongruité d’une réponse 200 OK en cas d’erreur (nous y reviendrons).

Cette approche revient à mettre en place un simple système RPC (Remote Procédure Call). Elle met en œuvre les mêmes mécanismes que SOAP ou XML-RPC, mais en s’affranchissant des enveloppes inhérentes à ces mécanismes. Les messages échangés sont du POX (Plain Old XML).

Le niveau 1 : l’utilisation de ressources différenciées

Dans le Richardson Maturity Model, le premier pas vers l’utilisation de REST consiste à introduire la notion de ressource. Ce qui est somme toute assez logique, puisque REST est un modèle d’architecture basé sur la manipulation de ressources (tout est ressource).
Ainsi, là où au niveau 0, toutes les requêtes étaient faites vers un unique endpoint (une unique URI), au niveau 1, les requêtes sont envoyées à des ressources individuelles : dans l’exemple de Martin Fowler, des médecins et des créneaux.

La première requête (pour demander les créneaux disponibles) se fait vers l’URI d’une ressource de type médecin :

POST /doctors/mjones HTTP/1.1
[various other headers]
<openSlotRequest date = "2010-01-04"/>

La requête étant faite sur un médecin (une ressource) particulier, le flux XML ne spécifie plus cette information.

La réponse du serveur est en substance la même, mais elle fournit maintenant pour chaque créneau un identifiant de ressource : chaque créneau est maintenant une ressource qui peut être requêtée individuellement :

HTTP/1.1 200 OK
[various headers]
<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

La requête de réservation d’un créneau se fait maintenant sur la ressource idoine :

POST /slots/1234 HTTP/1.1
[various other headers]
<appointmentRequest>
  <patient id = "jsmith"/>
</appointmentRequest>

La réponse renvoyée par le serveur est la même qu’au niveau 0.

Au niveau 1, l’introduction des ressources nous permet de gérer la complexité de notre système (de notre API de réservation) par l’approche « divide & conquer » : nous avons éclaté un service en plusieurs ressources.

Le niveau 2 : L’utilisation des verbes et des codes retours HTTP

La deuxième étape de l’approche prônée par le Richardson Maturity Model est d’introduire l’utilisation des verbes et des codes retours HTTP. Dans REST, les ressources sont manipulées au travers d’un jeu de verbes simples. Le plus souvent les verbes HTTP pour la simple et bonne raison que la majeure partie des implémentations REST se fait sur HTTP.

L’idée est de tirer parti du protocole sur lequel nous nous appuyons. Ainsi, au niveau 2, Martin Fowler déroule son exemple de la façon suivante :

La première requête (pour demander les créneaux disponibles) se fait en utilisant une requête GET (et non plus POST) :

GET /doctors/mjones/slots?date=20100104&status=open HTTP/1.1
Host: royalhope.nhs.uk

La réponse à cette requête est la même qu’au niveau 1.

Pour rappel, HTTP définit GET comme une opération « sécurisée » qui n’induit aucun changement d’état côté serveur. Cette particularité présente deux avantages :

• Les requêtes GET peuvent être invoquées autant de fois qu’on le souhaite dans n’importe quel ordre : la réponse à une requête sera toujours la même (sauf bien sûr si l’état de la ressource a été modifié par ailleurs).
• Les résultats des requêtes GET peuvent être mis en cache par les différents équipements intervenant dans la chaîne de routage de la requête (dans un système comme celui de l’exemple déroulé par Martin Folwer, il conviendra évidement de régler correctement le « cache timeout »).

La requête de réservation d’un créneau est la même qu’au niveau 1 (en POST).

Les réponses retournées par le serveur sont les mêmes qu’au niveau 1 à l’exception du code retour utilisé :

• Si la demande aboutie, le serveur retourne un code 201 Created : ce code réponse indique clairement qu’une nouvelle ressource a été créée. L’URI de cette ressource est contenue dans la réponse : Location : slots/1234/appointment (la ressource elle-même, dans sa représentation XML, est également retournée afin d’éviter une requête supplémentaire au client). L’indication fournie par le code retour est plus riche qu’avec un simple 200 OK.

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]
<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
</appointment>

• Si la demande échoue, le serveur retourne un code 409 Conflict : ce code réponse indique clairement que la requête n’a pas aboutit en raison d’un conflit (le créneau est déjà réservé). L’utilisation d’un code en 4XX a ici beaucoup plus de sens que celle du 200 OK qui devient fallacieuse quand on retourne une erreur.

HTTP/1.1 409 Conflict
[various headers]
<openSlotList>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650"/>
</openSlotList>

Au niveau 2, l’utilisation des verbes et codes retours standards de HTTP nous permet de tirer pleinement parti du protocole sur lequel nous nous appuyons (« By following the rules of HTTP we’re able to take advantage of that capability. »).
Cette approche nous permet également d’éliminer les variantes dans la façon de traiter les choses et ainsi, de gérer des cas similaires de façon semblable dans l’ensemble de notre API.

A propos de l’utilisation des standards HTTP, Martin Fowler soulève un point très intéressant. Comme il l’explique, les partisans de REST poussent à l’utilisation de l’ensemble des verbes HTTP (ce qui permet de disposer d’une sémantique CRUD). Or, un argument souvent avancé est que le modèle REST a fait ses preuves à très grande échelle : internet est construit sur une architecture REST. En effet, cet argument est inattaquable quand il s’agit d’utiliser POST et GET, mais il devient beaucoup plus discutable quand on parle de l’utilisation des verbes PUT et DELETE.

Le niveau 3 : L’utilisation des contrôles hypermédia

Le troisième et dernier niveau du Richardson Maturity Model introduit la notion de HATEOAS (Hypertext As The Engine Of Application State). Derrière cet acronyme barbare se cache un principe simple : les transitions possibles vers les états suivants sont fournies par des liens hypermédia.

Les requêtes sont les mêmes qu’au niveau 2, mais les réponses sont ici enrichies avec, pour chaque ressource, un élément link fournissant l’URI permettant de la manipuler.
Ainsi, dans l’exemple de Martin Fowler, la réponse à la requête de demande de créneaux libres est :

HTTP/1.1 200 OK
[various headers]
<openSlotList>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450">
     <link rel = "royalhope.nhs.uk/linkrels/slot/book"
           uri = "slots/1234"/>
  </slot>
  <slot id = "5678" doctor = "mjones" start = "1600" end = "1650">
     <link rel = "royalhope.nhs.uk/linkrels/slot/book"
           uri = "slots/5678"/>
  </slot>
</openSlotList>

Et la réponse à la requête de réservation d’un créneau est :

HTTP/1.1 201 Created
Location: slots/1234/appointment
[various headers]
<appointment>
  <slot id = "1234" doctor = "mjones" start = "1400" end = "1450"/>
  <patient id = "jsmith"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/cancel"
        uri = "slots/1234/appointment"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/addTest"
        uri = "slots/1234/appointment/tests"/>
  <link rel = "self"
        uri = "slots/1234/appointment"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/changeTime"
        uri = "doctors/mjones/slots?date=20100104@status=open"/>
  <link rel = "royalhope.nhs.uk/linkrels/appointment/updateContactInfo"
        uri = "patients/jsmith/contactInfo"/>
  <link rel = "royalhope.nhs.uk/linkrels/help"
        uri = "help/appointment"/>
</appointment>

Le premier avantage de l’utilisation des contrôles hypermédia est que les développeurs côté serveur peuvent refactorer les URI d’accès à l’API sans impacter les clients (pour autant que les clients utilisent les URI fournies par les éléments link).

D’autre part, l’utilisation des contrôles hypermédia permet d’auto-documenter l’API REST. Même si cette approche ne suffit pas à documenter complètement l’API, elle fournit un premier niveau d’information :

• Elle aide les utilisateurs de l’API REST (les développeurs de clients) à explorer ses capacités : chaque réponse indique ce qu’il est possible de faire après en indiquant les ressources manipulables (on notera que les éléments link ne fournissent pas d’indication sur les verbes utilisables).
• Elle permet aux développeurs de l’API de communiquer sur les nouvelles fonctionnalités en ajoutant de nouveaux éléments link dans les réponses.

Perspectives

Le Richardson Maturity Model propose un fil conducteur permettant d’appréhender pas à pas les concepts sous-jacents à une approche RESTFul :

• Niveau 1 : Gérer la complexité de notre système via l’approche « divide & conquer » en introduisant la notion de ressource.
• Niveau 2 : Eliminer les variantes dans la façon de traiter les choses et de gérer des cas similaires de façon semblable en introduisant un jeu de verbes standards pour manipuler les ressources.
• Niveau 3 : Auto-documenter le protocole et fournir un premier niveau de découvrabilité au travers de la notion de HATEOAS.

Le Richardson Maturity Model fournit aussi un biais intéressant pour évaluer la « RESTitude » d’une architecture.

• Le catalogue numérique.
• Le catalogue PDF.

Xebia Training se positionne logiquement dans la continuité de Xebia, tant sur la qualité de son offre de formation technique que méthodologique (méthodes agiles), en proposant des formations haut de gamme animées uniquement par les référents de leur domaine.

Avec pour principe premier le refus de tout compromis sur la qualité du formateur et du contenu, Xebia Training fait systématiquement intervenir des acteurs de références dans leurs domaines respectifs.

Nos formations, savant équilibre entre théorie et travaux pratiques, sont destinées à un large public soucieux d’acquérir les meilleures pratiques de notre industrie.

AMQP (Advanced Message Queuing Protocol) est un protocole de messagerie créé à l’initiative de la banque JP Morgan Chase pour gérer la communication entre ses différents partenaires. Le but affiché était de fournir une solution alternative aux solutions payantes et relativement chères dans le domaine du MOM (Message-Oriented Middleware) dominé largement par Websphere MQ d’IBM et RendezVous de Tibco (93% du marché à eux deux en 2008). Un certain nombre de partenaires se sont fédérés autour de ce projet pour aboutir à une première spécification en 2006. L’ambition avouée est qu’elle devienne l’équivalent du HTTP pour l’internet, ce qui explique qu’elle décrive aussi bien les différentes sémantiques liées au MOM que la partie plus bas niveau du transport de ces messages. Cette normalisation permet la multiplication des solutions clientes ou serveurs dont la compatibilité sera garantie par cette spécification. Par exemple, un broker de message écrit en Erlang comme RabbitMQ transférera de façon transparente un message d’un client ruby vers un autre client Java/JMS.

Notez bien qu’AMQP s’identifie clairement comme un protocole et non comme une API, contrairement à JMS. Donc un client Java basé sur JMS peut, moyennant des adaptations plus ou moins coûteuses, communiquer avec un broker AMQP.

Un nouveau protocole

Les spécifications AMQP sont parties de cas d’utilisation très concrets pour aboutir à des spécifications essayant d’englober un maximum de typologies. Voici quelques unes d’entre elles (QPid ou RabbitMQ) :

• Store-and-forward: les messages sont persistés puis récupérés par un seul client qui décidera s’il faut les supprimer.
• Point-to-point: une communication dédiée entre un émetteur et un receveur, éventuellement bidirectionnelle.
• One-to-many (ou fanout): un message est retransmis à toutes les queues d’une zone d’échange. Ceci permet de modéliser le multicast.
• Transaction (distribuée ou pas): l’émetteur peut englober un paquet de messages dans une transaction, ces messages ne pourront être lus que lorsque l’émetteur les aura acquittés.
• Publish-subscribe (pub-sub): plusieurs émetteurs postent des messages en fonction de mots clés (topics) auxquels s’abonnent plusieurs receveurs.
• Content-based routing: le routage des messages est déterminé selon le contenu du message ou par une fonction externe.
• Queued file transfer: on n’envoie plus de simples messages mais des fichiers, voire tout le contenu d’un répertoire.

Ces différentes architectures se combinent bien sûr entre elles, je pense particulièrement aux transactions. Ces schémas de base un peu abstraits rejoignent des concepts ou des applications connus de tous. Un serveur de mail par exemple s’appuiera sur un « store-and-forward », un chat sur un « point-to-point » ou un streaming de fichier sur un « queued file transfer ». Cette sémantique est un vrai plus pour la phase de conception d’un projet même si ensuite rien n’est figé dans la réalisation.

Derrière ces grands concepts se cachent des briques élémentaires très simples :

• Queue de message (Message Queue): zone de stockage des messages (en mémoire ou sur le disque). Elle aura les propriétés privée/partagée, durable/transitoire, permanente/temporaire.
• Zone d’échange (Exchange): l’entité qui accepte les messages et les route vers les queues de messages. Les critères de routage peuvent se faire de plusieurs façons (inspection du contenu, du header, clés de routage…). Les zones d’échange peuvent être créées dynamiquement par les applications clientes.
• Zone virtuelle (Virtual Zone): ce concept est copié de celui des serveurs HTTP d’Apache. Cette zone crée un espace contenant différentes zones d’échange et de queues de message complètement étanches aux autres zones virtuelles. Donc une connexion au serveur ne pourra être associée qu’à une zone virtuelle. C’est très utile lorsqu’on veut mutualiser les ressources.

Pour le routage, la zone d’échange pourra implémenter différents algorithmes :

• Direct: la clé de routage correspond exactement à l’adresse de la queue.
• Topic: la clé de routage correspond à un certain pattern (une expression régulière) de l’adresse de la queue.
• Routage par le header: analyse une table clé/valeur pour décider vers quelle queue aller.
• Système : appel à un service externe.

De même les queues de message peuvent avoir des typologies assez variées: durables après un redémarrage de serveur, auto-suppression si plus utilisées, dépendant d’un souscripteur, partagées par plusieurs souscripteurs, répondant à un message particulier…

La gestion des transactions et des transactions distribuées est également spécifiée. Un message envoyé à l’intérieur d’une transaction ne sera récupéré par les souscripteurs qu’à partir du moment où l’émetteur acquittera la transaction. Cependant, cette gestion peut varier selon l’implémentation des serveurs car lors d’un rollback, seules les commandes de l’émetteur sont dépilées. Certains états du serveur peuvent donc être modifiés malgré tout (par exemple la déclaration d’une nouvelle queue de message).

Solutions existantes :

RabbitMQ (Mozilla Public License) est sans doute le broker AMQP le plus connu. Il est basé sur le langage Erlang et ses librairies OTP, développé par Ericsson et réputé pour sa haute-disponibilité et sa tolérance aux pannes (règle des « nine nines » : 99.9999999% de disponibilité !). Au-delà de sa maturité, le point fort de ce produit est sa volonté de faciliter son intégration dans les systèmes existants. Par exemple, des distributions dédiées à Amazon EC2, avec intégration à EBS, sont proposées. La gestion du cluster est également très simple, en une commande on peut rattacher un broker à un autre. Toutes les zones d’échange, les queues de message ou les zones virtuelles seront alors partagées et répliquées. Côté client, une API Java est incluse dans la distribution, très simple et proche de l’API JMS. La communication avec un client JMS est possible grâce à une librairie proposée par OpenAMQ.

OpenAMQ propose lui-même un broker. Développé par iMatix, en C++, une API (WireAPI) est proposée. Sans doute plus complexe à appréhender, un effort particulier a néanmoins été apporté aux outils de développement (débogage, constructions de test…) et de monitoring (log, tuning…). Un langage XML (PAL) a été développé pour scripter des scénarios utiles pour les tests par exemple. Ou encore une console de monitoring pour serveur AMQP. Très pointu, OpenAMQ semble s’adresser à des experts confrontés à des projets soumis à de fortes contraintes. Il y a un côté un peu R&D qui permet par ailleurs de jouer un rôle moteur dans la communauté. A noter également que la distribution linux vient avec une implémentation de RestMS.

Par ailleurs OpenAMQ a fait main basse sur un autre broker AMQP : ZeroMQ. Enfin plus précisément un broker qui implémente plusieurs protocoles dont AMQP. On est ici à la limite du sujet tant cette application s’attache moins à son intégration dans une application de gestion classique qu’à construire une bête de course aux performances affichées impressionnantes (13.4 microsecondes de latence end-to-end, 4.1 millions de messages à la seconde).

Avec Qpid on revient un peu sur terre. Ce broker est incubé chez Apache et ne semble a priori rien apporter de plus que ceux cités plus haut. Il vaut malgré tout le coup de s’y intéresser pour les différents frameworks et librairies auxquels il s’intègre et en premier lieu celles d’Apache (Axis2, Camel, Synapse). Il est également intégré à la distribution de Red Hat MRG et est compatible avec l’outil de visualisation et de contrôle HermesJMS.

A noter également que le projet très en vue HornetQ de JBoss prévoit également de supporter ce protocole dans une prochaine version.

Perspectives et enjeux

Une communauté

La capacité d’AMQP à s’imposer comme un standard sera liée à sa capacité à drainer une vraie communauté autour de lui. Cette communauté se divise en deux actuellement : les membres du groupe de travail AMQP et la communauté open source.

Les membres du groupe de standardisation sont eux-mêmes divisés en trois familles : des fournisseurs de brokers AMQP (RabbitMQ, OpenAMQ…), les clients historiques (JPMorgan, Goldman Sachs…) qui poussent ces solutions et les fournisseurs de solutions matérielles (Cisco, Solace Systems Inc., Tervela Inc. …). Ce mélange a le gros avantage de proposer d’ores et déjà des solutions implémentées et en production qui éprouvent ce standard et l’enrichissent en retour. La réalité du terrain guide largement les spécifications comme le montre leurs Business Requirements.

Du côté OpenSource par contre la communauté reste encore discrète. En faisant une recherche rapide sur internet on trouve tout de même une bonne quantité de projets, plus ou moins expérimentaux :

• RestMS pour poster des messages directement en Rest.
• amqp-js pour poster des messages en javascript.
• ici une idée pour faire du twitter avec html5.
• réplication en base de données.
• des librairies spring pour utiliser de façon transparente les brokers.

Du chemin reste encore à faire, mais la diversité des projets prouve malgré tout qu’il y a une demande.

Une version de référence

Pour l’instant la version 0.10 est la dernière version officielle. Mais la plupart des brokers sont en version 0.8 ou 0.9. En effet, tout le monde attend la vraie version de référence, la 1.0. qui devrait sortir cette année. Elle devrait apporter de gros changements : un système d’adressage inspiré des mails (queue_message@my_server), le remplacement des zones d’échanges par deux nouvelles entités (une queue d’entrée et un service d’échange), la suppression des Virtual Hosts (conséquence de la suppression des zones d’échanges), l’amélioration de la partie administration du broker et l’ajout de support pour les services DNS.

Ces gros changements apportent sûrement des améliorations majeures à ce protocole. Il n’y a plus qu’à espérer que la migration se fera rapidement. Il est difficile de dire aujourd’hui si les clients sur les versions 0.x pourront se connecter à cette nouvelle version de façon transparente, mais si ce n’est pas le cas, cela risque de casser la dynamique autour d’AMQP.

La concurrence

La lutte est assez féroce dans le domaine du MOM. Si on met de côté Websphere MQ et Tibco, il existe de nombreuses solutions, parfois assez éloignées conceptuellement.

On peut s’en douter, ActiveMQ ne reste pas les bras croisés. Ils poussent entre autre une solution générique, STOMP, très simple d’utilisation mais moins complète et moins performante. Ils annoncent aussi une compatibilité AMQP, sans qu’on sache très bien comment.

Jusqu’à un certain point, ce protocole rentre également en concurrence avec XMPP, le protocole de messagerie instantanée.

MuleMQ est apparu également sur la scène et est proposé comme broker dans la nouvelle distribution de l’ESB Mule. C’est un broker JMS fourni avec quelques outils. Le « tout-intégré » de cette solution peut être assez attirant, par contre on peut regretter que MuleSoft s’éloigne de plus en plus de l’Open Source.

Au contraire, HornetQ joue le jeu de l’Open Source et peut profiter de la grande expérience de JBoss dans ce domaine. Mais cela reste du JMS… Cela sera sûrement la solution privilégiée pour les applications tournant sur JBoss mais difficile de dire si la solution out of the box aura du succès.

Au final JMS est le vrai concurrent d’AMQP même si encore une fois les deux peuvent vivre ensemble. Un adaptateur JMS pour AMQP peut sembler intéressant pour des projets qui migrent vers un nouveau broker, mais il semble plus pertinent pour un nouveau projet de commencer directement dans ce nouveau standard. Par exemple l’utilisation de la librairie Java de RabbitMQ est vraiment très proche de l’API JMS et la vitesse d’apprentissage semble assez rapide pour un développeur Java.

Car un des problèmes de JMS c’est justement son manque d’interopérabilité avec d’autres langages. A cet égard il est intéressant de remarquer que Microsoft s’intéresse de près à AMQP. Depuis 2008 il participe au groupe de travail et a collaboré activement avec QPid pour la version C++ du broker. Etre agnostique vis-à-vis de l’environnement DotNet ou Java serait sûrement une carte majeure de ce standard.

Conclusion

Les solutions propriétaires comme IBM et Tibco ne sont pas réellement menacées par ce nouveau concurrent car leurs solutions sont très complètes, éprouvées et ils fournissent un support sérieux qui rassure les DSI. Le défi d’AMQP est moins de concurrencer ces leaders que de promouvoir l’architecture orientée message au sein de projets de taille moyenne et/ou open-source qui n’ont pas forcément un gros budget à investir. L’adoption massive de ce modèle de conception imposerait AMQP comme le protocole référent tant sa spécification est avancée et complète.

Pourquoi ce réflexe :

• Par habitude ?
• Parce que Drools est l’unique solution du marché Open Source ?

Mais avant j’aimerais répondre à plusieurs questions :

• Qu’est ce qu’un moteur de règles ?
• Quand en a-t-on besoin ?
• Pourquoi en a-t-on besoin ?

Ensuite on pourra présenter Drools !

Qu’est ce qu’un moteur de règles, et pourquoi ?

Vu de l’extérieur, un moteur de règles est un système capable de définir des règles et de les appliquer à des faits. En vulgarisant, un fait est une donnée.
Un moteur de règles est la solution idéale pour les programmes contenant une logique nécessitant un nombre important de « if » (i.e. potentiellement détectable avec un outil d’analyse de la qualité du code, dans la rubrique complexité cyclomatique).

En regardant sous le capot, un moteur de règles est plus complexe. Les règles et les faits sont injectées à un moteur d’inférence. Ce moteur d’inférence cherche les règles applicables aux faits (pattern matching). Tout se passe en mémoire. C’est à dire que la règle a le même cycle de vie qu’une donnée. Une règle peut être chargée, déchargée ou modifiée en mémoire sans réinitialisation du moteur de règles. Ensuite, le moteur de règles optimise l’exécution de règles en les agençant de la manière la plus efficace possible (agenda).

Un moteur de règles permet donc d’isoler le traitement (règles), des données (faits). De plus il permet par exemple de gérer des algorithmes avec de nombreuses micros règles qui changent souvent. Idéal, donc pour des algorithmes implémentant une logique commerciale, très variable suivant les demandes des équipes marketing. Voici un cas d’utilisation possible pour un site d’ecommerce de vente de fruits et légumes : un algorithme métier qui calcule le prix total d’une commande, applique des promotions suivant de nombreuses conditions sur le panier et la fiche client.

La présentation

Chez Xebia, tous les premiers jeudis de chaque mois, il y a un XKE (Xebia Knowledge Exchange). C’est l’occasion pour tous les consultants de Xebia de se retrouver tous ensemble afin de partager sur divers sujets techniques ou d’architecture qui nous tiennent à coeur.

Lors du XKE de décembre, j’ai présenté une session sur les moteurs de règles et le framework Drools (JBoss).

Cette présentation aborde plusieurs points :

• Qu’est-ce qu’un moteur de règles ?
• Drools, les alternatives et son historique.
• Résumé d’un comparatif de moteur de règles.
• Première règle, une règle simple !
• Règles lisibles pour un humain (DSL et Table de décision).
• Drools Guvnor (BRMS/BPMS, système de gestion de régles métiers).
• Drools Flow (Flow/WorkFlow).
• Drools Fusion (Event Processing).
• Performance : Algorithme de Rete

La présentation fut dense. En effet, le focus a été mis sur la dernière version de Drools, la version 5, qui propose énormément de fonctionnalités. De plus, c’est un framework complexe qui demande une immersion longue – plusieurs mois – afin d’être autonome sur le produit. Certes, il propose de résoudre des problèmes non communs dans le monde du développement d’applications de gestion mais le choix d’une telle solution demande une étude approfondie en tenant compte de différents aspects :

• Besoin d’un moteur de règles, une solution de gestion de règles plus simple peut suffire comme par exemple le pattern Specification,
• Coût et temps :
• de formation des développeurs
• pour la réalisation d’un prototype,
• Performance,
• Processus de gestion des règles (qui va administrer et configurer les règles).

Selon moi, les avantages de Drools sont :

• La résolution de manière efficace d’algorithmes non classiques.
• La table de décision via un fichier Excel qui est très proche d’une spécification et ainsi évite une translation vers du code pas souvent agréable à maintenir.
• Drools Guvnor, une application Web afin d’administrer et modifier à chaud les règles via une interface graphique.
• L’intégration de Drools peut se faire seulement sur un point particulier de l’application, pour un algorithme par exemple. Cela aura pas d’impact sur le reste de l’appplication.

Drools permet de gérer les règles via une IHM grâce au composant Guvnor.

Création d’une règle avec Guvnor

Modification d’une règle avec Guvnor

Gestion d’une table de décision avec Guvnor

Passage obligé de toute présentation sur SOA, Nicolai Josuttis commence par introduire l’ensemble des concepts gravitant autour de l’architecture orientée services. Nous passerons sur ces rappels ici, car malgré quelques divergences dans les définitions, on retrouve les idées décrites dans les différents articles portant sur SOA que nous avons pu publier jusqu’alors.

Après cette introduction, Nicolai Josuttis s’est arrêté sur les débats ayant agité le petit monde des SOAistes en ce début d’année : ce modèle d’architecture est-il mort ? N’était-ce qu’une mode de passage ? Non, le concept de service garde toute sa valeur pour l’entreprise et la suite de sa présentation, sans rien cacher des défauts de SOA, montrera tout son intérêt.

La suite de la présentation s’oriente rapidement autour de la mise en pratique de ces concepts.

SOA en pratique dans l’entreprise

Entre frontends et backends

Une architecture orientée services repose en général sur un ensemble de frontends et une série de backends idéalement organisés en respectant les frontières des départements ou des business units de l’entreprise. La figure suivante représente ce type de système :

Le frontend peut prendre plusieurs formes. Il peut s’agir d’une simple interface de visualisation qui se contente alors de présenter les données formées par les services d’agrégation sous-jacents. A l’inverse, il peut permettre la modification des données, ce qui en fait une application plus intelligente. Il est alors également nécessaire de faire un choix quant à la validation des données entrantes : celle-ci peut se faire dans le frontend, dans le frontend et le backend, ou via un service dédié. Cette dernière solution simplifie l’architecture en assurant la cohérence de la validation mais entraîne une grande quantité d’invocations de services.

Versionning

Les services exposés dans une SOA subissent en général des modifications au cours de leur vie car ils mettent en œuvre des besoins en perpétuelle évolution. Les consommateurs ne pouvant alors être tous mis à jour lorsque le service évolue, plusieurs versions vont coexister.

Nicolai Josuttis préconise alors de limiter à 3 le nombre de versions d’un même service en production. Pour cela :

• Il est nécessaire que les consommateurs d’une version obsolète d’un service fassent évoluer leur application afin d’exploiter la version la plus récente.
• Le point précédent implique qu’une collaboration est nécessaire entre producteur et consommateur.
• Il implique également qu’il est vital d’être en mesure d’énumérer l’ensemble des consommateurs d’un service.

Interrogé sur le positionnement de nouveaux framework tels que Apache Thrift gérant nativement la problématique de versionning, Nicolai Josuttis explique qu’il s’agit là d’un détail d’implémentation qui ne doit pas être une justification pour contourner le nombre maximum de versions simultanément en production.

Ré-utilisabilité

La ré-utilisabilité est une des propriétés fondamentales des services dans une SOA.

Pourtant, Nicolai Josuttis a pu observer qu’en pratique cette propriété est rarement possible. En effet, il explique que ses observations ont montré que la majorité des services d’un système d’information ont au plus deux consommateurs. Certains ne sont même pas consommés.

Dans la mesure où la ré-utilisabilité va souvent à l’encontre des performances puisqu’il est alors souvent nécessaire d’invoquer plusieurs services, il est conseillé de se fixer des objectifs raisonnables quant à cette propriété.

Annuaires

Les annuaires de services permettent de recenser l’ensemble des services disponibles dans une SOA.

Nicolai Josuttis préconise de ne pas mettre en œuvre d’annuaire dès la création de l’architecture orientée services, mais d’attendre que le besoin s’en fasse naturellement ressentir.

Gouvernance

La SOA faisant interagir l’ensemble des départements de l’entreprise, des aspects humains et des problématiques de gouvernance surviennent inévitablement.

Il est suggéré de recourir à une équipe SOA dédiée, assurant le respect d’une stratégie d’architecture globale.

Lors de l’émergence de SOA dans l’entreprise, il est indispensable de procéder progressivement, en lançant des projets pilotes permettant de détecter les problématiques et d’adapter les équipes à cette nouvelle architecture. Ainsi le processus de transition peut prendre 5 ans.

SOA à l’heure du bilan

Après avoir énuméré l’ensemble de ces problématiques propres à SOA, Nicolai Josuttis pose une question simple : compte-tenu de tous ces défauts, pourquoi passer à SOA ? Il répond simplement en montrant que dans de nombreuses situations, ce modèle d’architecture n’est pas contournable pour satisfaire les besoins de communications entre les composantes de l’entreprise.

Enfin, il reconnait et dénonce le hype qui a entouré SOA, mais n’en minimise pas l’intérêt pour autant.

Conclusion

L’architecture orientée services aurait-elle atteint la maturité ? C’est en tout cas l’impression qui transparaît face à la multiplication de présentations telles que celle de Nicolai Jusuttis, imprégnées de pragmatisme et de réalisme, tout en montrant son rôle incontournable dans le remplacement des systèmes monolithiques ou organisés en silos isolés.

L’apparition d’outils et de frameworks légers tranchant avec les solutions très lourdes que SOA a connu dans ses débuts, ainsi que la percée des méthodes agiles pour leur mise en œuvre, s’ajoutent à ces nouveaux discours pour constituer le renouveau des architectures orientées services.

Le référentiel de service est un incontournable pour maîtriser les services.

Traditionnellement, et de façon macroscopique, un référentiel de services dans une architecture distribuée comprend deux grandes catégories de fonctionnalités :

• Les fonctions de registre qui visent à faciliter le fonctionnement de l’infrastructure de services :
• Contrôle d’accès.
• Correspondance entre les différents noms que peut porter chaque service dans les différents sous-systèmes.
• Localisation et routage.
• Transcodification et uniformisation des codes (y compris les codes erreurs).
• …
• Les fonctions d’annuaire qui visent à consolider la connaissance métier :
• Etre la référence unique portant la connaissance des services de l’entreprise.
• Porter la connaissance des formats d’échanges.
• Distinguer les services qui nécessitent une réponse de ceux qui n’en attendent pas.
• Identifier l’appartenance fonctionnelle de chaque flux.
• Gérer les versions.
• …

Les fonctions de registre sont destinées à l’exécution des services. Elles permettent aux consommateurs de services de localiser les fournisseurs (dans la version adéquate), d’identifier les modalités techniques de l’interaction, de valider les formats d’échange et de vérifier les politiques d’accès. Elles adressent aussi la dimension routage à savoir qu’à partir des informations de contexte, elles offrent la possibilité de déterminer le service cible, le mode d’accès (M.O.M., Web Services, …), les ressources associées (nom de la file MQ, URL d’accès, etc.).
Ces fonctions de registre s’appuient le plus souvent sur le standard UDDI v3, et un ensemble de standards complémentaires pour les différentes métadonnées et stratégies (WSDL 1.1, SOAP w/wo Attachement 1.1, OASIS Web Service Security, XACML 1.0, SAML 2.0).

Les fonctions d’annuaire, quant à elles, offrent une large palette de fonctionnalités destinées aux personnels impliqués dans la mise en œuvre de la SOA : modélisation et structuration du référentiel, accès à la documentation des services, recherche, gestion du cycle de vie (éventuellement avec des processus d’approbation), analyse d’impact, reporting, etc. Ces fonctionnalités sont proposées au travers d’interfaces graphiques plus ou moins sophistiquées et ergonomiques.
Ces fonctions ne font pas l’objet de standards, et sont en conséquence un facteur de différenciation fort entre les offres logicielles.

Le référentiel assure donc la cohérence entre les différentes nomenclatures des applications.
Dans son acception classique, le référentiel doit être et rester l’unique point de référencement des services. Il constitue un composant central de l’architecture, et nécessite à ce titre des procédures de gestion et d’administration adaptées.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de composabilité.

Un service doit être composable, c’est-à-dire être conçu de façon à participer à des compositions de services.

Ce huitième et dernier aspect constitue en quelque sorte l’aboutissement des sept précédents. En effet, l’ensemble des principes présentés dans cette série vise in fine à la réutilisation des services. Or, cette réutilisabilité n’a de sens que si les services sont effectivement réutilisés en prenant part à des compositions de services.

C’est grâce à la composabilité que sera mis en œuvre le principe de « separation of concerns » au sein d’une architecture orientée services. L’objectif est ici de déterminer la « bonne » granularité de services afin de décomposer la solution à un problème métier de haut niveau en un ensemble de « plus petites unités réutilisables » de traitement : les services.
L’idée est de pouvoir recomposer notre logique métier à l’infini au sein de processus ou de services composites de haut niveau.

La mise en œuvre de cet aspect dans une architecture de services pose donc le problème du bon niveau de granularité pour un service :

• Un service trop large ne pourra pas être réutilisé, car il implémente un enchainement de traitements qui n’ont, a priori, de sens que dans le contexte où le service a été écrit. Un service trop large n’est utilisable que par une seule (ou quelques) application(s).
• A l’opposé, un service trop fin ne sera pas réutilisé, car il implémente un traitement atomique qui n’apporte pas de valeur ajoutée. Un service trop fin propose un niveau de détail qui n’est pas pertinent d’un point de vue métier.

D’autre part, il faut garder à l’esprit que, d’un point de vue technique (runtime), un service ne sera composable que s’il est autonome et stateless (c’est-à-dire réutilisable).

Déterminer le niveau de granularité adéquat pour les services d’un écosystème est un exercice délicat, qui exige des connaissances (en grande partie métier), de l’expertise et l’expérimentation de différentes options.
La réussite de cet exercice permettra de maximiser la composabilité du portfolio de services, pré-requis indispensable à l’atteinte d’un des objectifs phares de la mise en œuvre d’une architecture à base de services : la réutilisation des services en vue de l’agilisation du SI, indispensable à la réduction du time-to-market, principal élément de ROI des SOA.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de « découvrabilité« .

Nous l’avons dit et répété tout au long cette série, la réutilisabilité des services constitue une des pierres angulaires de la mise en œuvre d’une architecture orientée service. En effet, la mise en œuvre d’une SOA vise, entre autres, à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle en silo. D’autre part, la réutilisation est une condition première de l’agilisation du SI indispensable à la réduction du time-to-market, principal élément de ROI des SOA.

Le positionnement des services comme ressources réutilisables au sein de l’entreprise passe par :

• La prédictibilité des services proposés (ce qui implique que les services soient autonomes et sans état).
• La découvrabilité des services existants.

Écartons tout de suite le mythe de la découvrabilité au runtime qui reste un espoir inabouti (ou une promesse non tenue) : Un service répondant aux besoins et contraintes d’un consommateur potentiel ne peut être identifié que par un acteur humain. Nous parlons donc bien ici de découverte des services en phase de conception.

Cette découvrabilité des services existants passe par la mise en œuvre d’un repository de services qui vient outiller l’inventaire des services disponibles. Ce repository stocke l’ensemble des métadonnées nécessaires à :

• La recherche des services de l’inventaire.
• La récupération de l’ensemble des artefacts relatifs aux services de l’inventaire (Spécifications, SLAs, Policies, Schémas XML, WSDL, Interfaces, …).

Remarque : Attention à ne pas confondre le repository de services avec un registre de services qui a lui la responsabilité de référencer pour le runtime les endpoints (points d’accès physiques) des services déployés.

Ainsi, le concepteur d’un consommateur de service (Service composé, application composite, orchestration, processus, …) pourra s’appuyer sur ce repository de la façon suivante :

• Le concepteur recherche dans le repository un service possédant les fonctionnalités dont il a besoin (1).
• En se basant sur les métadonnées contenues dans le repository, le concepteur est capable de découvrir et d’identifier un service potentiellement capable de répondre à ces besoins (2).
• le concepteur peut alors accéder au contrat du service : syntaxique, sémantique et de niveau de service (3). il est alors capable, en se basant sur les différents artefacts constituant le contrat du service (spécifications, SLAs, policies, syntaxe, …), de déterminer si le service découvert correspond bien à ces attentes.

Afin qu’il remplisse au mieux son rôle, les fonctionnalités attendues d’un repository de service sont :

• Le catalogage des services, de leurs métadonnées et des artéfacts relatifs à ces services.
• La validation des services et artéfacts catalogués vis-à-vis des standards de l’entreprise.
• La gestion des dépendances entre les services et les artéfacts.
• Le versioning des services et de leurs différents artéfacts.
• La gouvernance de la publication au sein du repository.
• Le support d’un large panel de type d’artéfacts.

Le repository de services constitue donc un outillage indispensable à la découvrabilité de l’inventaire des services. Il permet une gestion centralisée de l’ensemble des données relatives aux services, devenant ainsi un des éléments centraux autour desquels s’articulera la gouvernance SOA.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de « statelessness« .

Comme nous l’avons expliqué dans le précédent billet de cette série : Mettre l’emphase sur la réutilisabilité des services commence par la fourniture de services proposant une logique réutilisable, mais implique également que l’implémentation de cette logique soit effectivement réutilisable une fois déployée.
Dans une optique de sollicitation massive, il est important de concevoir l’implémentation des services en prêtant tout particulièrement attention à la concurrence d’accès. Les accès concurrents à un service ne doivent en aucun cas modifier son comportement, sa fiabilité ou ses performances. En d’autres termes, un service doit respecter son contrat (et ses SLAs), quel que soit le volume de sollicitations auquel il est soumis : Un service doit être prédictible.
Afin de garantir cette prédictibilité dans le cadre d’accès concurrents, deux principes doivent être appliqués lors de l’élaboration des services :

• Un service doit (au maximum) être autonome.
• Un service doit être sans état.

Ces deux aspects sont fortement liés : Le principe d’autonomie des services implique que le comportement d’un service ne dépende pas du contexte dans lequel il est invoqué (contexte fonctionnel ou contexte technique). Dans cette optique, intégrer de la gestion d’états au sein de nos services est un non sens.

D’une manière plus générale, la gestion d’états (d’informations de contexte) au sein d’un service pose des problèmes :

• De compréhension et de maintenabilité :
  La gestion d’états va sensiblement augmenter la complexité cyclomatique de l’implémentation et donc rendre difficile sa lecture, sa documentation, sa testabilité (plus cette complexité cyclomatique est élevée, plus il est difficile d’obtenir une couverture de code acceptable), … Dans le cadre d’une composition de services, la complexité du composé étant directement liée à celle de ses composants, la complexité des services de plus haut niveau peut donc rapidement devenir ingérable.
• De réutilisation :
  La gestion d’états au sein du service brouille la lisibilité de son contrat puisque l’adaptation de son comportement en fonction de son état ne transparaît pas dans son contrat. Or la lisibilité et la transparence des contrats de service sont des facteurs clés de la réutilisation des services.
  D’autre part, l’utilisation d’états au sein d’un service présuppose souvent l’utilisation de ce service au sein d’un enchaînement d’invocations défini à l’avance. Il sera donc difficile de réutiliser le service au sein d’une autre orchestration ou composition.
• De performances : car la gestion des état est consommatrice de ressources systèmes, notamment en terme de stockage de ces états (en mémoire ou sur disque).

On préférera donc la conception et l’implémentation de services stateless. La responsabilité de la gestion d’états sera alors déléguée aux utilisateurs (consommateurs) des services : compositions, orchestrations, processus, … Ce transfert de responsabilité (déléguer la gestion d’états au client) rejoint les principes d’une approche REST des services.

Le sujet de l’émission était « Le retour sur investissement des infrastructures informatiques«  :

• Comment calculer le retour sur investissement (ROI) des infrastructures informatiques ?
• Comment aligner ces infrastructures sur la stratégie de l’entreprise ?
• Quel ROI apporte la mise en œuvre des SOA (Architectures Orientées Services) ?

Bonne écoute.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion d’autonomie.

Comme nous l’avons vu dans le précédent billet de cette série : La réutilisabilité des services constitue une des pierres angulaires de la mise en œuvre d’une architecture orientée service. En effet, la mise en œuvre d’une SOA vise, entre autres, à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle en silo. D’autre part, la réutilisation est une condition première de l’agilisation du SI indispensable à la réduction du time-to-market, principal élément de ROI des SOA.
Mettre l’emphase sur la réutilisabilité des services commence bien sûr par la fourniture de services proposant une logique réutilisable, mais cela implique également que l’implémentation de cette logique soit effectivement réutilisable une fois déployée. La confrontation au monde réel est souvent douloureuse.
En effet, le modèle SOA pousse à maximiser les possibilités de réutilisation des services produits. Les services identifiés comme réutilisables sont ainsi mis à disposition d’un large spectre de services composites, de processus, d’applications, … Au fil du temps, de tels services ont donc vocation à prendre part à un nombre croissant de compositions, d’orchestrations, de workflow, …
Dans cette optique de sollicitation massive, il est donc important de concevoir l’implémentation des services en prêtant tout particulièrement attention à la concurrence d’accès. Les accès concurrents à un service ne doivent en aucun cas modifier son comportement, sa fiabilité ou ses performances. En d’autres termes, un service doit respecter son contrat (et ses SLAs), quelque soit le volume de sollicitations auquel il est soumis : Un service doit être prédictible.

Afin de garantir cette prédictibilité dans le cadre d’accès concurrents, deux principes doivent être appliqués lors de l’élaboration des services :

• Un service doit (au maximum) être autonome.
• Un service doit être sans état.

Ces deux aspects sont fortement liés. En attendant le billet consacré à la notion de « statelessness des services », je vous invite à relire l’article Service Stateful vs. Service Stateless.

Afin que les services s’acquittent au mieux de leurs engagements (comportement, fiabilité, performances, …), ils doivent exercer un contrôle fort sur leur environnement d’exécution et sur les ressources qui sous-tendent leur implémentation. L’autonomie d’un service traduit la mesure du degré de contrôle qu’un service exerce sur son environnement. Plus un service à de contrôle sur son environnement (plus il est autonome), plus son comportement au runtime sera prévisible.
Lors de la décomposition des fonctions du SI en inventaire de services, il est souhaitable de définir les membres de ce registre comme des blocs indépendants. C’est donc un haut niveau d’autonomie individuelle des services qui est visé. Réduire l’accès partagé aux ressources d’un service et augmenter le niveau d’isolation physique des services sont deux leviers permettant d’augmenter cette capacité des services à fonctionner de façon autonome.

Tous les services d’un inventaire ne pourront évidement pas offrir un contrôle complet sur leur environnement. C’est pourquoi Thomas Erl propose de distinguer deux niveaux basiques d’autonomie :

• L’autonomie de niveau service : Les frontières des services entrant dans cette catégorie sont clairement définies et les services sont indépendants les uns des autres, mais il se peut que ces services partagent encore certaines ressources sur lesquelles ils s’appuient. Par exemple, un service d’encapsulation d’un système legacy, même s’il régit ce système partage cette ressource avec ses autres clients.
• L’autonomie pure : La logique sous-jacente au service et les ressources qu’il utilise sont la propriété du service et sous son contrôle exclusif. C’est le niveau d’autonomie que l’on pourra atteindre lors de la création de « nouveaux » services quand la logique sous-jacente est construite spécifiquement pour supporter le service.

La mise en œuvre d’une SOA se faisant, dans la grande majorité des cas, au sein d’un existant avec lequel il faut vivre pendant longtemps (la refonte de tout ou partie du SI en mode big-bang est trop coûteuse et trop risquée), un inventaire de services offrant exclusivement des services d’ un niveau d’autonomie pure reste un objectif difficilement atteignable. C’est pourtant cet objectif qu’il faut viser car un tel inventaire de service permet d’adresser nos préoccupations de monté en charge et de concurrence d’accès.

La mise en œuvre du principe d’autonomie est donc extrêmement importante car elle détermine dans quel mesure les autres principes peuvent être mis en application dans le monde réel (nos environnements de production) en favorisant la fiabilité et la prédictibilité des services.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de réutilisabilité.

La réutilisabilité des services (et plus largement des ressources du SI) constitue une des pierres angulaires de la mise en œuvre d’une architecture orientée service. En effet, la mise en œuvre d’une SOA vise, entre autres, à éviter le gaspillage des ressources en éliminant les redondances inhérentes au modèle en silo. D’autre part, la réutilisation (et donc la réutilisabilité) est une condition première de l’agilisation du SI indispensable à la réduction du time-to-market, principal élément de ROI des SOA.

La production de services réutilisables passe par la combinaison des processus d’ingénierie logicielle traditionnels et des processus de production industrielle à destination de la consommation de masse. En effet, même si les méthodologues n’ont de cesse de proposer un mode de production standard des projets informatiques, force est de constater que le cycle de production d’un projet informatique lui est souvent spécifique. Les logiciels ainsi produits sont destinés à un usage précis au sein du SI et proposent un potentiel de réutilisabilité quasi nul. A l’inverse, les chaines de production pour l’industrie de masse visent à la production de produits génériques et standardisés offrant un fort potentiel de réutilisabilité.
L’objectif est de produire un registre de services offrant un très fort potentiel de réutilisabilité et qui soit effectivement réutilisé (cette deuxième partie étant souvent plus difficile).

Pour ce faire, il est essentiel de mettre en application le concept de centralisation de la logique métier qui veut que chaque fonction logique offerte par le SI ne soit accessible que par un seul point d’entrée (1) : le service qui l’implémente. Cette approche est indispensable au positionnement des services comme ressources réutilisables au sein de l’entreprise.

La combinaison de la centralisation des contrats de service (qui garantie qu’un consommateur n’a accès au service que par son contrat (2)) et de cette centralisation de la logique métier permet d’obtenir un inventaire de services hautement normalisé. La standardisation de cet inventaire est essentielle pour maximiser la réutilisabilité (et la réutilisation) des services disponibles au sein de l’entreprise. Elle facilitera également le couplage lâche des consommateurs aux services.

Ainsi, les processus organisationnels de production logiciels doivent êtres revus pour garantir la centralisation de la logique métier. Lors de la conception d’un processus ou d’un service composite, ces processus organisationnels doivent inclure systématiquement une recherche dans l’inventaire des services existants. Si la logique métier recherchée existe déjà dans cet inventaire, le service qui l’implémente doit être réutilisé. Dans le cas contraire, son implémentation doit être faite sous forme de service avec une vision élargie (plus large que sa simple utilisation dans le cadre du processus concerné).
C’est pourquoi, comme nous l’expliquions dans « Mise en œuvre d’une SOA : Les clés du succès« , la mise en place d’une SOA est un effort (une initiative) qui doit être mené de façon transverse. Elle ne peut pas être traitée projet par projet.

Le principal frein à la réutilisation des services est la résistance au changement et les guerres de chapelle.
Comme le faisait remarquer Bruno en commentaire au billet « SOA : Du composant au service : Le contrat standardisé« , « dans une organisation multi-partite on n’utilise pas un service parce qu’il existe, mais parce qu’on en a le droit ; et ce droit est donné par un/des urbanistes qui gèrent de facto les mises en relation. ». C’est en effet le cas dans certaines organisations. On retombe ici dans les travers liés à la propriété des composants et au financement au projet.
C’est malheureusement pour cela que dans de nombreuses structures (notamment les plus larges), la réutilisation effective des services reste un vœu pieux.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion d’abstraction.

Le principe d’abstraction consiste à fournir les services du SI sur un modèle boîte noire.
Dans ce modèle, les seules informations accessibles aux consommateurs d’un service sont celles contenues dans son contrat. Ainsi, les concepteurs et développeurs d’un consommateur de service ne sont pas au courant de la façon dont est implémenté le service.
C’est pourquoi, nous l’avons vu, il est important d’assurer un couplage lâche des consommateurs aux services. Dans ce modèle, il est également très important d’assurer la prédictibilité d’un service : le comportement d’un service et la réponse qu’il donne à une requête ne doit pas varier. Cette prédictibilité du service est induite par le respect de son contrat.

Le principe d’abstraction promeut donc l’offuscation délibérée d’un ensemble de données relatives aux services exposés afin qu’un minimum d’information soit accessible aux consommateurs potentiels.

Ainsi, il est (par exemple) préférable de ne pas diffuser les détails de conception et d’implémentation d’un service et de proposer ici un accès contrôlé. Même, si les développeurs ayant le réflexe de se plonger dans le code source des plateformes qu’ils utilisent sont malheureusement trop rares, cette mesure encourage le positionnement des services en tant que ressources agnostiques et réutilisables. Elle contribue également à forger une relation de confiance entre producteurs et consommateurs de services ou tout du moins leur « impose » de dialoguer, ce qui ne peut pas être mauvais.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce billet, nous nous attarderons sur la notion de couplage lâche.

Comme nous l’expliquions dans notre livre blanc « Comprendre et savoir utiliser un ESB dans une SOA« , la formalisation du paradigme SOA a clairement eu le mérite de replacer le métier au centre de l’architecture du SI. Mais SOA reste aussi un projet d’intégration à grande échelle. Il est dès lors primordial d’éviter les chausse-trappes des grands projets d’architectures distribuées ou intégrées, et en particulier le couplage technique et fonctionnel entre consommateurs et fournisseurs de services.
Le couplage technique impose au consommateur de connaître le protocole d’échange du fournisseur. À grande échelle, un tel couplage complique, voire interdit l’évolution du socle technique, et risque de figer le SI dans une inertie sclérosante.
À la fois plus subtil et plus pernicieux, le couplage fonctionnel impose au client de connaître le format d’échange du fournisseur. Toute évolution du fournisseur a un impact potentiel sur chacun de ses consommateurs. Mal gérée, cette dépendance peut conduire à de véritables verrous fonctionnels dans le Système d’Informations – interdisant toute évolution ou, plus sûrement, augmentant de façon exponentielle le coût de ces évolutions.

L’implémentation d’un service dépend de son environnement

C’est une évidence, la logique d’un service est, par nature, fortement liée à son environnement :

• Tout d’abord, la logique d’un service est directement dépendante de son implémentation (1). Cette implémentation s’appuie sur un ensemble de ressources qui constituent l’environnement d’implémentation du service. La logique d’un service est donc couplée à ces ressources.
• De la même façon, la logique d’un service est fortement liée aux technologies sur lesquelles son implémentation s’adosse (2).
• D’autre part, dans le cadre de services composites, la logique d’un service est également dépendante des services qui le composent (3).
• Enfin, le contrat de service ainsi que sa logique peuvent être couplés aux processus qui les utilisent (4).

Ces couplages sont inévitables.

Le couplage Contrat / Service

Le contrat d’un service et sa logique peuvent être couplés de deux façons différentes :

• Couplage du contrat de service vers la logique d’implémentation du service (B) :
  Un tel couplage résulte d’une approche contract last lors du design du service (le contrat dérive de l’implémentation). Cette approche, nous allons le voir, est à proscrire car elle induit un couplage du contrat avec l’environnement du service.
• Couplage de la logique du service au contrat (A) :
  Ce couplage dénote une approche contract first dans la conception du service (le contrat est écrit préalablement à l’implémentation du service). Cette approche est toujours préférable et le couplage du service vers son contrat est considéré comme un couplage positif.

Établir la dépendance dans le bon sens

Les consommateurs d’un service sont liés au contrat de ce dernier, et ne doivent être liés qu’à celui-ci (Pas au service lui-même). C’est ce que l’on appelle le couplage lâche.
Or, si le contrat est couplé avec la logique du service (B), les consommateurs vont hériter par transitivité de l’ensemble des dépendances de la logique du service avec son environnement. Nous nous retrouvons donc avec des consommateurs qui sont fortement couplés au service.

C’est pourquoi il est préférable d’établir le couplage du service vers son contrat (A).

Perspectives

Les équipes en charge de la conception des consommateurs ne sont pas nécessairement au courant du couplage du contrat à la logique (B). Ainsi, une telle situation aboutit à un ensemble de couplages non désirés et ignorés des consommateurs à l’environnement du service.
La prolifération de tels couplages est catastrophique car ils fragilisent et rendent moins flexible l’ensemble de l’architecture de service (SOA). C’est pourquoi, les approches contract last sont à proscrire.
À l’inverse, les approches contract first sont à encourager car elles permettent d’imposer (via le contrat) un couplage lâche des clients au service, permettant ainsi l’évolution des implémentations sans impact sur les consommateurs.

On pourrait proposer la définition suivante : « Un Service est un composant logiciel distribué, exposant les fonctionnalités à forte valeur ajoutée d’un domaine métier ». Malheureusement, les définitions aussi courtes (bien qu’exactes) sont nécessairement incomplètes et amènent un florilège de questions.

Pour répondre plus précisément à la question, nous vous proposons de passer en revue les huit aspects qui caractérisent un service :

• Contrat standardisé : L’ensemble des services d’un même Système Technique sont exposés au travers de contrats respectant les mêmes règles de standardisation.
• Couplage lâche : Le contrat d’un service doit imposer un couplage lâche de ses clients.
• Abstraction : Le contrat d’un service ne doit contenir que les informations essentielles à son invocation. Seules ces informations doivent être publiées.
• Réutilisabilité : Un service exprime une logique agnostique et peut ainsi être positionné comme une ressource réutilisable.
• Autonomie : Un service doit exercer un contrôle fort sur son environnement d’exécution sous-jacent. Plus ce contrôle est fort, plus l’exécution d’un service est prédictible.
• Stateless (sans état) : Un service doit minimiser la consommation de ressources en déléguant la gestion des informations d’état quand cela est nécessaire.
• Découvrabilité : Un service est complété par un ensemble de métas données de communication au travers desquelles il peut être découvert et interprété de façon effective.
• Composabilité : Un service doit être conçu de façon à participer à des compositions de services.

Ces 8 aspects sont issus du livre « SOA Principles of Service Design » de Thomas Erl, également auteur du site SOA Principles.

Dans ce premier billet, nous nous attarderons sur la notion de contrat standardisé.

Qu’est-ce qu’un contrat de service ?

Le contrat de service définit un accord entre le fournisseur et le consommateur. Il est composé :

• D’un contrat syntaxique qui propose une représentation technique du service :
  Il constitue le contrat d’utilisation du service (son interface). Il présente le nom du traitement, ses paramètres d’entrée et de sortie et les contraintes structurelles (format et contrainte sur les données) qui s’y appliquent.
• D’un contrat sémantique qui fournit une description informelle du traitement :
  Il précise les règles et contraintes d’utilisation du service : La valorisation des messages de réponse (0 représente-t-il le résultat d’un calcul, une erreur, une interruption de service ?) ; Les exceptions ; les pré et post conditions techniques (ex. : volume des données échangées) ou métiers (ex. : écriture comptable équilibrée).
• D’un contrat de niveau de service (QoS & SLA) qui précise les engagements du service :
  Il spécifie par exemple le temps de réponse maximum attendu, les plages horaires d’accessibilité, le temps de reprise après interruption, les procédures mises en œuvre en cas de panne, les procédures de prise en charge du support, …

Par exemple, lorsqu’un service est implémenté sous forme de Web Service (nous parlons bien ici d’un exemple ; il ne faut pas confondre service et Web Service), son contrat est composé :

• D’une WSDL qui décrit les modalités d’accès au(x) service(s) :
  La WSDL fait partie du contrat syntaxique. Elle fournit l’interface du service.
• D’un ensemble de XSD qui définissent les types de données échangées par le service :
  Les XSD font partie du contrat syntaxique. Elles définissent les formats de données et les contraintes structurelles.
  Les XSD font également partie du contrat sémantique. En effet, la richesse des types et restrictions XSD permet d’auto-documenter les valeurs possibles et permet souvent d’éviter des quiproquos.
• D’un ensemble de policies qui définissent les règles d’utilisation du service :
  Les policies font parties du contrat sémantique. Les règles et contraintes qu’elles expriment adressent des domaines variés : Sécurité, encodage, langue, versioning, métiers, …
• De documentations complémentaires.
  Ces documentations complètent le contrat sémantique. C’est par exemple dans les spécifications que l’on décrira les pré et post condition d’utilisation du service (elles ne sont pas toutes implémentables sous forme de policy).
  Ces documentations constituent le contrat de niveau de service (QoS & SLA). Notons que l’on parle bien d’un contrat qui définit un ensemble d’indicateurs et de valeurs seuils. Il n’est pas question ici des moyens techniques à mettre en œuvre pour leur supervision (traces, alertes, …).

Standardiser pour faciliter la communication

Le contrat de service est donc une notion complexe qui ne se limite pas à la (simple) définition d’interfaces. Un contrat de service est constitué de nombreux éléments (techniques ou non) qui forment un fond documentaire pour lequel il est préférable (voire indispensable) de respecter un formalisme commun. L’utilisation de ce formalisme commun est le meilleur moyen de construire un modèle cohérent et donc facile à comprendre et à partager.

La notion de contrat de service standardisé ramène à celle de contract first qui est, comme nous l’évoquions dans notre billet sur l’interopérabilité des Web Services (sans, une fois de plus, limiter la notion de service à ceux-ci), la meilleure approche de conception de services (voire la seule valable ?). Dans cette approche, les contrats font l’objet de développements spécifiques en amont de l’implémentation de la logique du service. Le développement de ces contrats doit se faire suivant des règles de standardisation établies pour l’ensemble des services d’un même Système Technique.

Centraliser pour encourager la réutilisation

En plus de cadrer la définition des contrats (et donc de faciliter la communication), l’utilisation d’un formalisme commun et de règles de standardisations facilite la centralisation des éléments constituant les contrats. Cette centralisation encourage la réutilisation. Parmi les constituants des contrats de services, deux sont de particulièrement bons candidats à la réutilisation :

• Les règles d’utilisation (policies) :
  Les contraintes de sécurité, d’encodage, de versioning sont souvent communes à l’ensemble (ou à un sous-ensemble) des services d’un domaine. De la même façon, les règles métiers sont rarement applicables à un seul service.
• Les formats de données (XSDs) :
  Il est évident que les types et formats de données sont utilisés par plusieurs services. Ces derniers ont même vocation à être utilisés au-delà des services : les types et formats de données sont souvent les mêmes pour les invocations synchrones de service et pour les échanges asynchrones, par exemple au travers d’un bus.

Pour rendre possible leur réutilisation, il est indispensable de séparer les différents éléments du contrat de service. Plusieurs WSDL pourront ainsi appliquer les mêmes règles (policies) et manipuler les mêmes types de données (XSDs).

L’isolation des différents constituants du contrat de service en vue de leur réalisation est une bonne pratique qui tient du bon sens. Il n’est pourtant pas rare de voir des déclarations de type (XSDs) au sein d’une WSDL plutôt qu’un import. Cette approche est aussi aberrante que la re-déclaration en inner class de l’ensemble des types de données manipulés par un Bean (Cette pratique doit être restreinte à des cas bien spécifiques et constituer une exception).

Perspectives

La standardisation des contrats de service est donc un élément fondamental de la mise en œuvre d’architectures orientées services (SOA). En effet, la mise en place des bonnes pratiques évoquées dans ce billet offre des gains importants sur deux axes clés :

• Faciliter la communication et le partage de la connaissance :
  La définition d’un ensemble de principes communs de conception des contrats (ex. : conventions de nommage claires pour les entités, les attributs et les relations) permet d’aboutir à un modèle plus cohérent et donc plus facile à comprendre, partager, (ré)utiliser.
• Encourager la réutilisation :
  L’isolation et la centralisation des différents constituants des contrats de services facilitent indéniablement leur réutilisation.

Il ne faut pas perdre de vue que la définition de certains de ces éléments dépasse le simple cadre des contrats de service. Il est par exemple souhaitable que les types et formats de données manipulés par les services soient également utilisés au sein des flux d’intégration. Cette pratique, même si la définition d’un Modèle de Données Canonique reste un exercice difficile, est un gage sur le long terme de maintenabilité, de stabilité et de pérennité.

Dans ce billet, nous reviendrons rapidement sur la galaxie des standards Web Services, avant de présenter la Web Service Interoperability Organization (WS-I org.) et ses travaux.
Nous nous attarderons ensuite sur les profils proposés par le WS-I puis sur les outils qu’il met à disposition.
Nous terminerons avec quelques recommandations quant à l’implémentation de Web Services conformes aux profils du WS-I.

La galaxie des standards Web Services

L’équation de départ se voulait simple :

• Des standards basés sur XML, un langage autodescriptif que l’on présente comme l’esperanto de l’informatique (il est compréhensible au-delà des limites technologiques et, pour peu qu’il soit bien écrit, reste lisible par une personne sans connaissances en programmation).
• Un triptyque fournissant :
  • Un protocole d’échange : SOAP
  • Un langage de définition d’interfaces : WSDL (cet IDL fournit un premier pas vers la description de contrats).
  • Un modèle d’annuaire de services : UDDI (d’entrée trop complexe, UDDI a rapidement été mis de côté, même s’il est censé se relever depuis la version 3).

Mais à peine cette première stack adoptée, elle a montré ses limites et de nouveaux besoins se sont fait sentir engendrant une armée de standards (regroupés sous le nom de WS-*).

• Pour le messaging, avec par exemple, WS-Adressing.
• Pour la gestion des métadonnées. Citons WS-Policy.
• Pour la fiabilisation avec WS-Reliability et WS- Reliable-Messaging.
• Pour la sécurité avec WS-Security et ses add-ons.
• Pour la gestion transactionnelle avec, entre autres, WS-Coordination et WS-Atomic Transaction.
• Pour la gestion des ressources.
• Pour les processus métier avec, par exemple, WS-Choreography Model.
• Pour la gestion avec WS-Management.
• …

Ajoutez à cela la dépendance entre ces différents standards, nous obtenons une galaxie plutôt dense de standards ou propositions de standards.

Ces standards sont poussés par une pléthore d’éditeurs et aboutissent (éventuellement) chez 2 organismes de standardisation : l’OASIS et le W3C.

Chacun fournissant une (ou plusieurs) implémentation(s) de ces standards, on aboutit à un modèle qui a peu de chance d’être interopérable out-of-the-box.

Web Service Interoperability Organization (WS-I org)

C’est face à ce constat que s’est créée la Web Service Interoperability Organization (WS-I org.).

Le WS-I est un consortium qui regroupe plus de 160 sociétés. Son objectif annoncé est de faire progresser l’interopérabilité des Web Services en établissant des bonnes pratiques autour des standards existants. Les travaux du WS-I sont menés en coopération avec les organismes de standardisation OASIS et W3C.

Le constat de départ du WS-I est simple :

• L’intérêt des Web Services réside dans l’interopérabilité. C’est grâce à elle que les Web Services permettront de répondre aux attentes qu’ils suscitent : Qualité, modularité, évolutivité et surtout réconciliation de Systèmes Techniques hétérogènes.
• L’adoption des Web Services et leur succès sont directement liés aux technologies qui les supportent.

Répondre à ces enjeux permettra :

• De réduire les coûts, la complexité et les risques, notamment en donnant confiance dans l’interopérabilité des Web Service.
• De faciliter les échanges et la collaboration, que ce soit au sein de son propre SI ou avec des Systèmes externes.

Pour arriver à cela, le WS-I élabore et propose trois types de livrables :

• Des profils qui regroupent des bonnes pratiques d’utilisation des standards en vue d’assurer l’interopérabilité des implémentations.
• Des exemples mettant en œuvre ces profils.
• Des outils de tests permettant de vérifier la conformité d’une implémentation à un ou plusieurs profils.

Les profils

Les profils proposés, même si certains sont encore à l’état de draft, couvrent aujourd’hui :

• La couche transport avec notamment HTTP, HTTPS, …
• La couche invocation c’est-à-dire XML, SOAP.
• La couche description de contrats avec entre autres XSD et WSDL, …
• Et aussi les aspects sécurité et Reliable messaging.

Voici comment s’articulent les différents profils :

• Le Basic Profile 1.1 constitue le socle des profils.
• La version 1.2 du Basic Profile, encore à l’état de DRAFT, l’étend en y ajoutant notamment le support de WS-Addressing.
• Le Basic Security Profile 1.0 y ajoute une dimension sécurité avec la prise en charge de WS-Security 1.0 et de SAML.
• Afin de suivre l’évolution des standards, un Basic profile 2.0 et un Basic Security Profile 1.1 sont en cours d’élaboration.

L’objectif à terme est de regrouper l’ensemble de ces profils au sein d’un Reliable Security Profile 1.0 qui couvrira, en plus de ceux adressés dans le Basic Profile 2.0 et le Basic Security Profile 1.1, les standards WS-Reliable Messaging et WS-Secure Conversation.

Les outils

Le WS-I propose deux outils de tests de conformité : Le Monitor et l’Analyzer.

• Le Monitor fonctionne comme un proxy. Il est configuré pour intercepter les requêtes et les réponses échangées entre un client et un Web Service. Ces requêtes et réponses sont tracées dans une base locale.
• L’Analyzer permet de tester la conformité à un profil. L’analyse peut porter :
• Sur une définition de contrat (WSDL, XSD).
• Sur le contenu d’un annuaire UDDI.
• Sur les traces générées par le monitor.

Perspectives

Nous l’avons vu, le modèle des WS-* a peu de chance d’être interopérable out of the box. L’utilisation de SOAP / WSDL à elle seule pose des problèmes d’interopérabilité.

L’utilisation des outils du WS-I au plus tôt dans le cycle de développement permet d’éviter de mauvaises surprises au moment de brancher les systèmes, que l’on soit dans la position d’un fournisseur ou d’un consommateur de services.
Chacun devrait au minimum utiliser systématiquement l’Analyzer pour s’assurer de la conformité des WSDL qu’il manipule au WS-I Basic Profile. Que l’on soit dans la position d’un consommateur ou d’un fournisseur de service.
De la même façon, la conformité au Basic Profile des Web Services produits devrait être systématiquement exigée dans un cahier des charges.

Attention cependant. La conformité aux profils du WS-I, même si elle protège de beaucoup de choses, ne garantit pas l’interopérabilité.

À noter également que l’écriture de Web Services en mode Contract First et l’utilisation de contrats orientés documents sont deux bonnes pratiques qui permettent, entre autres, d’écrire des Web Services conformes aux profils du WS-I.

Java Business Integration est une norme édictée dans la JSR-208 : basée sur une approche orientée composant, JBI définit la manière de router les messages entre composants. Elle définit les composants et leur rôle, les messages qui circulent dans le bus, les canaux de communication entre les composants ainsi que les patterns d’échange.

ServiceMix est une implémentation de la norme JBI.

Architecture de JBI

Le schéma ci-dessous présente l’architecture générale de JBI.

L’ensemble des éléments de ce schéma sera décrit dans la suite de cet article.

Notion de composants

Catégories de composants

JBI définit deux types de composants : Les Binding Components (BC) et les Service Engines (SE).

• Les Binding Components (BC)
  Les Binding Components permettent l’accès depuis l’extérieur au bus JBI. Ils peuvent à la fois exposer des services ou consommer des services disponibles sur des applications hors de l’ESB.
• Les Service Engines (SE)
  Les Services Engines exposent et consomment des services disponibles uniquement à l’intérieur du bus JBI. Ils ne peuvent accéder au monde extérieur.

Les rôles des composants JBI

Un composant JBI peut proposer des services suivant deux types de rôles :

• Rôle  » Provider  » :
       - Ce rôle est endossable par les Binding Components ou les Service Engines.
       - Un service de type provider fournit des services exposés en interne du bus JBI.
       - Exemples :
            - Un composant de transformation va offrir des services de transformations sur le bus JBI.
            - Un composant Web Service va permettre d’invoquer un Web Service extérieur à partir du bus JBI.
• Rôle  » Consumer  » :
       - Ce rôle n’est endossable que par les Binding Components.
       - Un service de type  » consumer  » écoute les messages provenant de l’extérieur et initie les échanges JBI à partir des messages qu’il reçoit.
       - Exemples :
            - Un composant va exposer un Web Service vers l’extérieur et envoyer chaque message qu’il reçoit dans le bus JBI.
            - Un composant va attendre des messages sur une file JMS et envoyer chaque message qu’il reçoit dans le bus JBI.

Un composant peut fournir à la fois des services consumer et provider.

Les composants : conteneurs de services

Les composants (BC & SE) une fois installés dans le bus JBI proposent des services. Les composants proposent différents services en fonction de leur technologie.

Exemple : Le composant de type SE servicemix-saxon offre des services de transformation XSL et XQuery, le composant de type BC permet d’exposer et d’invoquer des services externes au bus JBI, etc.

Ces services doivent être en quelque sorte configurés et instanciés pour s’exécuter. Les composants agissent ainsi comme des conteneurs pour des instances de service.

Les instances des services sont packagées sous la forme de Service Unit (SU). Ces services units sont ensuite déployés dans le bus JBI qui va installer chaque instance dans le composant (BC ou SE) fournissant le service.

Les services units doivent être packagés sous la forme de Service Assembly (SA) pour être « déployable ».

JBI définit un packaging standard (une archive Zip) et des descripteurs (fichier jbi.xml) pour l’installation et le déploiement des composants afin de permettre leur portabilité sur tous les ESB conformes à sa spécification, sans modification. Le package d’installation contient tout ce qui est nécessaire à l’installation d’un composant (librairies …).

Interaction entre les composants ServiceMix

Le Normalized Message Router (NMR)

JBI définit un concept de bus interne permettant la communication entre les composants : c’est le Normalized Message Router (NMR).

Les éléments qui composent ce NMR sont :

• NormalizedMessage : Cette interface de la spécification définit la structure standard d’un message. Ce format est utilisé pour représenter un message en entrée ou en sortie ainsi qu’un message d’erreur. Les messages transitent forcément sous la forme de message XML (implémentant l’interface javax.xml.transform.Source). Un message peut aussi contenir des propriétés et des attachements (binaires ou non).
• MessageExchange : Cette classe représente un appel transitant à l’intérieur du bus JBI. L’échange contient le message d’entrée, l’éventuel message de sortie ou d’erreur (sous la forme de NormalizedMessage) et véhicule aussi les informations de l’appel (ex : destinataire) et le statut (actif, fini, en erreur). Il existe plusieurs types de MessageExchange, chacun suivant un pattern d’échange défini dans JBI.
• DeliveryChannel (DC) : JBI fournit à chaque composant (BC ou SE) un channel d’échange avec le NMR. Les composants utilisent ce channel pour échanger des messages au travers du NMR.

L’implémentation des mécanismes de routage du NMR dépend de chaque solution d’implémentation de JBI. ServiceMix fournit une implémentation d’un NMR sous la forme de flow. Il existe trois types de flow dans ServiceMix : Le SedaFlow (défaut), le JMSFlow et la JCAFlow.

Le SedaFlow stocke les messages en mémoire, le JMSFlow utilise des queues JMS comme implémentation des DeliveryChannel et le JCAFlow se base sur un connecteur JCA pour stocker les messages.

Message Exchange Pattern (MEP)

JBI définit aussi des patterns d’échanges de message. Chaque composant supporte selon la technologie qu’il représente tout ou partie de ces patterns d’échanges.

Chaque MEP définit l’enchaînement, le sens et le nombre de messages échangés ainsi que l’évolution du statut de l’échange de manière précise.

Au travers du DeliveryChannel, les composants interagissent avec le NMR de deux façons :

• En acceptant des échanges (MessageExchange) : le composant reçoit un échange émis par un composant.
• En envoyant des échanges (MessageExchange) : le composant initie ou poursuit un échange après avoir traité les messages de l’échange.

Un Binding Component de type consumer initie un échange en créant une instance d’un objet MessageExchange et en le mettant à disposition des autres composants au travers du NMR. Un autre composant va accepter l’échange, effectuer un traitement puis envoyer l’échange (éventuellement mis à jour) vers le NMR, etc.

L’échange se termine quand l’un des composants positionne l’échange au statut ‘Done’ ou ‘Error’.

Les échanges entre les composants sont décrits au travers des patterns suivants. Il existe 4 MEPs différents basés sur les types d’invocations One-way et Request-Response. Ils permettent de moduler les types de communications entre les composants :

• In-Only (One-Way) : Le message est envoyé au destinataire. Aucun moyen n’est mis en œuvre pour s’assurer qu’il est bien arrivé ou non.
• Robust In-Only (One-Way) : Le message est envoyé au destinataire et un message (de type acknowledge) est retransmis à l’expéditeur en cas d’erreur.
• In-Out (Request-Response) : Un message nécessitant une réponse est envoyé au destinataire.
• In Optional-Out (Request-Response) : Un message est envoyé au destinataire et peut parfois nécessiter une réponse.

En exemple voici, un échange de type InOut décrit par des diagrammes de séquence UML, le premier finissant normalement, le second finissant en erreur.

Schéma d’un échange In Out se terminant normalement

 

Schéma d’un échange In Out se terminant en erreur

Cette présentation de JBI se termine ici, prochainement nous étudierons quelques exemples de mise en œuvre avec ServiceMix.