2 septembre 2010
La vie terrestre des ESB, aura été courte. À peine compris et apprivoisés, les voilà qui s’envolent vers d’autres cieux. En effet, depuis quelque temps, on commence à percevoir les premières initiatives d’ESB dans les nuages comme celle de la firme WSO2 avec sa plateforme Stratos ou encore celle de Savoir technologies, dans le milieu hospitalier, où la mise en place d’un ESB dans les nuages a facilité les échanges des données des patients entre les différents départements.
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.
Lire la suite de cet article »
25 juin 2010
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).
Ce billet présente le Richardson Maturity Model en s’appuyant en grande partie sur le papier de Martin Fowler. Au programme :
Lire la suite de cet article »
24 février 2010
Nous sommes heureux de vous proposer le nouveau catalogue de formation Xebia Traning :
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.
23 février 2010
Vous avez une application Java qui doit envoyer et recevoir des messages à droite et à gauche pour des raisons qui n’appartiennent qu’à vous… Votre premier réflexe sera sûrement de contacter votre vieil ami JMS. Pour ça, vous aurez aussi besoin d’un broker de message, mais vous n’êtes pas très riche et des outils comme WebSphere ou Tibco sont hors de portée… Vous aurez alors de fortes chances de vous tourner vers votre autre vieil ami ActiveMQ. Bon d’accord, l’amitié ça compte, mais par ailleurs d’autres amis (des vrais !) vous signalent qu’ils ont eu quelques problèmes de blocage de file avec ActiveMQ et qu’ils ont eu du mal à identifier ces problèmes. En plus vous avez encore d’autres amis qui aimeraient bien communiquer avec vous sur ce même broker mais leurs applications tournent en ruby et C++ qui parlent mal le JMS… C’est le moment idéal de vous présenter un nouvel ami : AMQP !
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.
Lire la suite de cet article »
23 novembre 2009
Les sessions dédiées à SOA étaient présentes cette année encore à Devoxx. Nicolai Josuttis a animé une présentation intitulée « SOA in practice » à l’image du titre du livre dont il est l’auteur, publié chez O’Reilly.
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.
Lire la suite de cet article »
30 octobre 2009
Dans une architecture orientée service, le référentiel ou catalogue de services appartient à une famille de composants destinés à ce que l’on appelle généralement la gouvernance. La gouvernance est une notion évanescente, dont la définition fait l’objet d’âpres débats, mais qui, quelle que soit celle que l’on retient, renvoie au besoin de se doter d’outils et de procédures susceptibles d’assurer le contrôle de la complexité de l’architecture et d’en mesurer la consistance.
Le référentiel de service est un incontournable pour maîtriser les services.
Lire la suite de cet article »
11 août 2009
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 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é.
Lire la suite de cet article »
12 juin 2009
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 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é« .
Lire la suite de cet article »
4 juin 2009
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 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« .
Lire la suite de cet article »
19 mai 2009
Ce jeudi 14 mai, Guillaume Bodet (Directeur Technique de Xebia) était l’invité de l’émission 01 Business sur BFM Radio en compagnie d’Yves Caseau (Directeur général adjoint en charge de la prospective, de la qualité, des services et de l’innovation chez Bouygues Télécom, dont il est ancien DSI) et de Michel Mariet (Responsable marketing middleware d’Oracle France).
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.
