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 d’autonomie.
Lire la suite de cet article »
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 réutilisabilité.
Lire la suite de cet article »
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 d’abstraction.
Lire la suite de cet article »
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 couplage lâche.
Lire la suite de cet article »
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 premier billet, nous nous attarderons sur la notion de contrat standardisé.
Lire la suite de cet article »
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, 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.
Lire la suite de cet article »
L’article du Touilleur Express (aka Nicolas Martignole) intitulé Exadel Flamingo : JBoss Seam et Adobe Flex ensembles m’a donné envie de tester les capacité de flamingo d’Exadel.
Exadel Flamingo fournit un ensemble de scripts, basés sur Maven, visant à simplifier le démarrage de projets RIA. Ces scripts permettent de générer le code initial et redondant d’un projet.
La promesse est donc d’offrir la capacité de créer une application CRUD dotée d’une interface riche très rapidement et sans effort de développement.
(Nous ne discuterons pas ici de l’intérêt ou non de doter une application de type CRUD d’une interface riche …)
Les technologies couvertes aujourd’hui sont :
- Flex et JavaFX pour partie cliente,
- AMF et Hessian pour la communication,
- JBoss Seam et Spring pour la partie serveur.
Question de contexte et de goût, j’ai pour ma part porté mon attention sur le triplet Flex / AMF / Spring.
Même si certains aspects méritent des améliorations, la promesse est tenue. Bien que n’ayant jamais pratiqué Flex (ou presque), il ne m’a pas fallu longtemps pour monter mon CRUD Flex / Spring / Hibernate.
Ce billet présente le déroulé de mes premiers essais.
Lire la suite de cet article »
Comme nous l’évoquions 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 à cette plate-forme de messaging.
Lire la suite de cet article »
Les mois de mai et juin ont été l’occasion de dérouler la série « Les 10 pièges de la SOA ».
Cette série proposée par nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington a pour objectif de vous faire partager nos expériences issues 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.
De par leur implication dans des projets SOA (Service Oriented Architecture), les consultants de Xebia vivent de belles réussites. Mais ils rencontrent aussi un certain nombre de projets qui peinent ou qui sont en échec.
Afin de partager ces expériences, nos collègues hollandais, Gero Vermaas, Viktor Grgic, Rik de Groot et Vincent Partington déroulent une série de billets présentant les 10 pièges de la mise en œuvre d’une architecture orientée services (SOA). Comme toujours dans ce genre de « classement », cette liste n’est ni exhaustive ni définitive.
Le dixième et dernier de ces pièges concerne les impacts culturels de la mise en place d’une architecture orientés service (SOA).
La mise en place d’une SOA implique une mutation profonde des façons de penser et de travailler. Comme pour les méthodes agiles, il ne suffit pas d’appliquer la culture SOA lors de la définition des architectures IT ou de la réalisation d’une application, mais il faut savoir la propager à l’ensemble des composantes d’une organisation.
Or, il semble que de nombreuses entreprises préfèrent investir dans des « outils SOA » plutôt que dans l’accompagnement des équipes qui vont mettre en œuvre et faire vivre cette SOA.
Lire la suite de cet article »
Complet
Twitter
