Le modèle de maturité de Richardson (Richardson Maturity Model) est un modèle qui décompose l’approche REST en trois étapes qui introduisent progressivement les principaux éléments de REST (Ressources ; Verbes et Codes retours HTTP ; Contrôles hypermédia) pour passer d’un modèle RPC sur HTTP à un modèle RESTFul.
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).
Dans le billet “REST : Richardson Maturity Model” publié sur le blog de Xebia France, nous présentons le Richardson Maturity Model en nous appuyant en grande partie sur le papier de Martin Fowler. Au programme :
Christophe Heubès SOA REST, RESTFul
Comme son nom le suggère, l’élément clé de SOA (Service Oriented Architecture) est le Service. Il est pourtant difficile de faire le consensus autour de la notion de service et il est souvent difficile de répondre à cette simple question “Qu’est-ce qu’un service ?”. Ce sujet débouche invariablement sur, au choix : Un blanc ; Une réponse alambiquée et incertaine ; Une discussion enflammée (ou un débat stérile).
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, dans cette série d’articles parus sur le blog de Xebia, 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.
Christophe Heubès SOA SOA
Alain Clapaud m’a fait le plaisir de m’interviewer dans le cadre de son article “Tibco porte sa plate-forme SOA sur Amazon EC2“ parru dans 01 Informatique.
Christophe Heubès SOA Amazon EC2, Cloud, SCA, Silver, SOA, Tibco
L’objectif initial des Web Services est de fournir un ensemble de standards permettant d’exposer des services de manière interopérable.
La mode du tout Web Service a rapidement mis en exergue les manques du triptyque de départ (WSDL, SOAP, UDDI) qui n’est plus qu’un diptyque. Par exemple, les aspects transactionnels en sont absents, ce qui impose de gérer des mécanismes de compensation. C’est alors que se sont mis à fleurir les WS-*. Même après consolidation et épuration, la confusion autour de ces standards est palpable et il semble illusoire d’aboutir à un modèle qui soit interpéropérable out-of-the-box.
C’est face à ce constat que s’est créée la Web Service Interoperability Organization (WS-I org.), consortium industriel dont l’objectif est d’établir et de diffuser un ensemble de best practices autour des standards Web Service, en vue de garantir l’interopérabilité des différentes implémentations et utilisations qui sont faites de cette pile de standards.
Dans ce billet, publié sur le blog de Xebia, 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.
Christophe Heubès SOA Web Services, WS-I
—
Entrée originale publiée dans la revue de presse Xebia du 12 janvier 2009.
—
Anne Thomas Manes, s’est fait son petit plaisir de début d’année en publiant lundi dernier, sur le blog “Application Platform” du Burton Group, un billet intitulé “SOA is Dead; Long Live Services“.
Elle y annonce la couleur d’entrée de jeux : “SOA met its demise on January 1, 2009, when it was wiped out by the catastrophic impact of the economic recession.”. En substance, alors que les SOAs étaient annoncées comme le paradigme d’architecture qui allait sauver les SI, elles ont en fait, après moult millions investis, empirées les choses (à quelques exceptions).
Les causes de ce fiasco ? D’après Anne Thomas Manes, pas les SOAs en tant que telles, rassurez vous. Si aujourd’hui, le métier ne croit plus aux promesses des SOAs, c’est avant tout un problème d’approche : Ceux qui ont compris que les SOAs n’étaient qu’un des outils du changement (changement organisationnel profond) ont profités d’un ROI énorme. Ouf !
Ce n’est donc pas aux funérailles des Architectures Orientées Services que le Burton Group nous convie en ce début d’années mais à celles de l’acronyme “SOA”, dont nous avons oublié le sens premier.
Lire la suite…
Christophe Heubès SOA SOA
Comme annoncé sur le blog de Xebia france dans le billet “Spring Integration - L’avènement des ‘lightweight ESB’ ?“, SpringSource a annoncé fin 2007 le lancement de Spring Integration, une implémentation légère des Enterprise Integration Patterns.
Le projet est aujourd’hui dans sa phase finale (la version courante est 1.0.0.M4). Mark Fisher apporte les dernières touches à Spring Integration : bugfix, refactoring, configuration, documentation, samples, …
L’occasion d’une introduction à Spring Integration, la plate-forme de messaging de SpringSource.
Christophe Heubès SOA ESB, Intégration, SOA, Spring
Les mois de mai et juin ont été l’occasion de dérouler sur le blog de Xebia France une série intitulée “Les 10 pièges de la SOA”. Cette série, à l’initiative de mes collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington a pour objectif de faire partager nos expériences issue de l’implication des consultants Xebia dans des projets SOA (Service Oriented Architecture).
La liste complète de ces pièges peut être ordonnée en trois catégories :
Les pièges liés à l’implémentation :
Les pièges liés à l’architecture et au design :
Les pièges liés à l’organisation :
Comme toujours dans ce genre de “classement”, cette liste n’est ni exhaustive ni définitive.
—
Article original : “Les 10 pièges de la SOA“ sur le le blog de Xebia France.
Christophe Heubès SOA
Les méthodes agiles et les architectures orientées services courent après la même quête : l’agilité du système d’information.
Sont-elles pour autant conciliables ? Les SOA peuvent-elles profiter des méthodes agiles ? Les unes et les autres sont-elles vraiment conciliables ?
Premiers éléments de réponse sur TV4IT par Guillaume Bodet, directeur technique de Xebia (interviewé par Cyril Dhénin).
Christophe Heubès SOA
Les ESB (Enterprise Service Bus) visent, d’une part à assurer l’interconnexion et d’autre part à gérer la médiation des communications et des interactions entre services et applications d’un SI. Quoique non indispensables, ils n’en demeurent pas moins une brique à forte valeur ajoutée dans le cadre d’une mise en place d’une architecture orientée service (SOA) mature.
Néanmoins les ESB sont aujourd’hui victimes de leur succès et il est souvent difficile de décrypter leur rôle exact.
L’objectif de ce livre blanc est de présenter les fonctionnalités que l’on peut attendre d’un ESB et comment il peut répondre aux besoins d’adaptation inter-applications d’une SOA.
Télécharger le Livre Blanc Comprendre et savoir utiliser un ESB dans une SOA.
Christophe Heubès Publications, SOA
Dans le cadre du séminaire “Les ESB dans la SOA : Comprendre & Savoir utiliser” donné par Xebia le 09/10/2007, Manuel Eveno et moi même vous proposons une série d’articles présentant différents cas d’utilisation d’un ESB :
Christophe Heubès SOA
