Tag Archives: soa

Granularité et atomicité des services

How big should a service be? C’est la question que pose InfoQ après la lecture de The Service Granularity Matrix par zapthink. Très bon article au coeur de la problématique SOA:

  • Quelle granularité pour les services, fine or coarse grained?
  • Un service est-il réutilisable? Atomique ou composite?

Pour chaque service identifié le choix se fera selon 5 aspects:

  • reusability
  • efficiency
  • transactionality
  • consumability
  • visibility

Des services fine-grained en premier lieu pensés comme composite deviendront un seul service coarsed-grained atomique pour garantir une transaction et l’efficacité. Un service coarsed-grained sera explosé en plusieurs services fine grained pour des raisons de réutilisation.
..

Que fait le mot “web” dans “web services” ?

A lire absolument: Position Paper For the Workshop on Web of Services for Enterprise Computing

L’introduction et la conclusion du papier:

Web Services based on SOAP and WSDL are “Web” in name only. In fact, they are a hostile overlay of the Web based on traditional enterprise middleware architectural styles that has fallen far short of expectations over the past decade.

[…]

It is my position that the W3C should extricate itself from further direct work on SOAP, WDSL, or any other WS-* specifications and redirect its resources into evangelizing and standardizing identifiers, formats, and protocols that exemplify Web architectural principles. This includes educating enterprise application architects how to design “applications” that are “native” web applications.

Ce papier a été rédigé pour un workshop du W3C, InfoQ avait couvert l’événement et vous pouvez désormais consulter le rapport final du workshop du W3C dont la position concernant le débat REST vs SOAP est bien plus nuancé.

From the REST vs. SOAP legacy, the consensus was that there is strength in both approaches and there is a need to identify how best to leverage those strengths

wsdeathstar.png

Intégration SOA avec Google reader et SimplePie

La lecture de ce retour d’expérience m’a ouvert les yeux: SOA integration with Flickr and del.icio.us. Comme Mr Jourdain fait de la prose, je fais de la SOA sans le savoir avec ce blog!!

En effet, le comité de pilotage exécutif de ce site de gestion personnelle du savoir et de la connaissance a récemment décidé d’intégrer à cette application des informations à haute valeur ajouté en provenance de notre application d’agrégation de nouvelles. Cette évolution nous permet d’enrichir l’expérience utilisateur afin de créer de la valeur, de développer notre part de marché et d’asseoir notre position de leader dans notre secteur d’activité.

Cet article détaille le travail de nos équipes ayant permit de relever ce défi. Après 10800 secondes/homme d’effort, l’utilisation d’une architecture SOA on demand et d’outils innovants à la pointe de la technologie nous ont permit d’obtenir une qualité de service optimale pour un coût de gestion réduit. Le retour sur investissement a été immédiat avec une croissance de +50% de notre trafic.

Le défi a relever:
Dans l’optique de minimiser les coûts et d’assurer une qualité de service irréprochable l’ensemble de notre système d’information est outsourcé sur la plateforme mutualisé du leader de l’hébergement haute performance: textdrive. Afin de fournir à nos utilisateurs cette application de gestion personnelle du savoir et de la connaissance nous avons déployé l’application open source de gestion de contenu WordPress qui a été enrichie des extensions fournie par K2.

Dans un marché en pleine expansion nous avons sélectionné l’aggrégateur/lecteur de news le plus adapté à notre besoin: Google reader. Extrêmement bien positionné dans les quadrants magique du Gartnerr, la commercialisation gratuite de cette offre en mode ASP en a fait un choix incontournable.

Nous avons fait appel à une équipe de consultants experts pour faire apparaître dans notre application de gestion du savoir et de la connaissance des informations à haute valeur ajouté sélectionné dans notre lecteur de news.

La solution
Pour répondre aux attentes du marché nous nous sommes naturellement orienté vers une solution de type SOA. Suivant les best pratices de la profession un système intermédiaire d’intégration d’application a été mis en place pour faire communiquer les deux systèmes entre eux, ce choix permet d’atteindre les objectifs de couplage lâche de toute architecture SOA.
Nous avons sélectionné l’EAI de type ESB-lite: SimplePie. Bien qu’en bêta le produit de cette startup en forte croissance propose déjà des fonctionnalité de niveau entreprise et le support des tout derniers standards du W3C: ATOM, WS-HTTP et WS-BLOG.
SimplePie fournit “out of the box” l’ensemble des fonctionnalités requises pour l’intégration d’application dans les entreprises conçue pour répondre au changement. Dans le même temps SimplePie est facilement customizable pour s’adapter aux besoins spécifiques de chaque client.
La preuve par les faits: notre directeur de la publication a pu lui même customizer et paramétrer SimplePie pour réaliser l’intégration de googleReader dans WordPress comme vous pouvez le constater sur la droite dans la section: “Dernières lectures en direct”.
Dans un premier temps, en raison de l’afflu de visiteur, le site a connu quelques problèmes de performance. Heureusement grâce à notre un contrat de support on-site 24/7 +1 un expert a depuis chez lui et en caleçon pu activer une fonction tout a fait innovante de SimplePie permettant de régler ces problèmes de performance. Il s’agit de la fonction: “cache”. SimplePie est le premier produit du marché à implémenter cette technologie ultra sophistiqué issue des travaux du MIT.

L’utilisation de l’architecture SOA et de produits à la pointe de la technologie participent pleinement à la réalisation de nos objectifs et nous donne une longueur d’avance sur la concurrence.

Le futur:
Nous prévoyons aussi l’intégration d’image en provenance de Flickr. Mais le cas Labnotes nous a mis en garde concernant les difficultés relatives aux différente tailles d’images. Nous avons donc commandé une étude à notre réseau de partenaires/consultants à valeur ajouté. Ils ont immédiatement identifié une difficulté supplémentaire: les images peuvent nous parvenir en noir et blanc mais aussi en 256 couleurs, voir en plusieurs millier ou million de couleurs! Au moment où j’écris ces lignes, nos experts ont encore des doutent sur la capacité de notre solution initiale à supporter une telle monté en charge.

S* oriented architecture

Comment faire pour passer de cela:
Un système d’information en silo où les applications sont cloissonées les unes des autres et ne communiquent pas ou peu entre elles.

SiloOA.png

A ceci :
Un système d’information où les applications communiquent abondament entre elles et sont construites en réutilisant des services qui exposent les fonctions de l’entreprise.

ServiceOA.png

La première question à se poser est de savoir si vous avez réellement intérêt à succomber à la mode SOA?
Rappelons qu’une architecture se choisi en fonction d’un besoin et non pas en fonction d’une mode ou des recommandations d’un vendeur de logiciels ou de matériels (voir les deux à la fois).

A quel besoin répond une architecture de style SOA?

Celui de réorganiser dans des délais court l’organisation d’une l’entreprise pour s’adapter rapidement à un environnement en perpétuelle évolution. Donc SOA n’est pas uniquement une mode mais répond bel et bien à un besoin de plus en plus répandu.

Comment SOA répond t-il à ce besoin?

La promesse SOA est le nirvana de l’informatique, notre Saint Graal à tous: la réutilisation! Des générations d’informaticiens se sont cassés les dents sur le problème. Ce coup ci serait-il le bon? Une seule certitude: Une architecture de type SOA coûte plus cher à mettre en place qu’une architecture plus traditionnelle et simple. Le ROI n’est à attendre que sur le moyen/long terme: lorsqu’une nouvelle application sera développée en s’appuyant sur des services déjà existant.
Chacun répondra à ces interrogations selon son contexte. Si vos réponses à ces questions vous confirment dans le choix d’une SOA, quelles sont les conditions du succès?

J’ai vu pas mal de projet aborder la problématique SOA d’un point de vue technique au niveau applicatif. En général on constate que ces projets ne produisent pas des services réutilisables. Pour quelles raisons?

Web services, SOAP, UDDI, EAI, WS-*… La liste des technos que l’on peut introduire sur un projet SOA est longue. En réalité HTTP + XML peuvent suffire pour faire fonctionner une architecture orienté service. Ca ne veut pas dire que les autres technos soient inutiles. Mais là aussi il faut se poser la question de leur utilité et s’assurer que l’équipe de développement les maîtrises avant de les introduire.

Ces problèmes techniques, bien que pouvant être complexes et importants, sont des détails par rapport aux problèmes organisationnels. Bien souvent on décide d’introduire une architecture SOA dans le cadre du développement d’une nouvelle application. L’objectif du projet et de répondre au besoin métier de l’application, l’architecture SOA n’est qu’un moyen. Le projet est porté, financé par une direction métier, les achats par exemple. L’objectif du responsable des achats est d’obtenir au moindre coût et dans les délais les plus courts une application qui va répondre aux besoins de son métier dont le périmètre se limite aux achats. Son objectif n’est pas de financer le développement de services qui pourront être réutilisé par son collègue des ressources humaines. Ces deux objectifs s’opposent, le résultat ne fait aucun doute, au fur et à mesure que le projet avance, que les retards s’accumulent, les principes qui font une SOA sont sacrifiés pour répondre aux impératif immédiat de l’application: adieu le plan d’urbanisation, au revoir l’indépendance des services…

Au final les services produits sont les services de l’application, pas les services de l’entreprise. Cette notion est développée dans ce billet: Intégration d’applications ou intégration ontologique ?

Au lieu d’une approche technique au niveau applicatif il faudrait mieux se concentrer sur une approche fonctionnelle au niveau de l’entreprise. C’est le rôle du(des) homme(s) en rouge sur mon deuxième schéma. Le développement des services doivent être des projets à part entière, ce sont des applications comme les autres, avec leur propre budget et leur responsable métier dont l’objectif sera de produire des services réutilisable par les autres applications. Ces responsables de services ne sont pas rattachés aux achats ou à la production, ils sont transverses à l’entreprise.

C’est à mon avis une condition indispensable pour produire des services réutilisables, ce qui reste l’objectif principale d’une SOA.

On dit souvent qu’une architecture SOA permet d’aligner le système d’information avec les métiers de l’entreprise. Cet alignement est réalisable si les services informatiques font la moitié du chemin et l’organisation de l’entreprise l’autre moitié. On tombe bien sûr tout de suite dans une problématique de conduite du changement.

A défaut d’effectuer ces changements on court le risque de se retrouver avec ce type d’architecture:

Des services qui complexifient le système sans permettre de réelle réutilisation.

SatanOA.png

A lire aussi:

Réutilisation et mode projet : la contradiction par Dominique Vauquier.