Le mécano SOA : les applications composites
Passer du Playmobil au Lego : un nouveau terrain de jeu pour les utilisateurs du SI (4ème épisode sur 6). Avez-vous déjà essayé d'assembler 2 Playmobils ? C'est la quadrature du cercle permanente pour les utilisateurs et les informaticiens à chaque nouveau projet informatique, et inévitablement on rachète une nouvelle boite, plus jolie, plus complète que la précédente mais avec les mêmes bonshommes de base.
PublicitéLe but du jeu : découplage et assemblage Le principe simplifié d'une architecture orientée services est de proposer un découpage du Système d'Information en « tranches » horizontales : - Une tranche applications de surface, - Une tranche middleware communiquant ou ESB (Enterprise Service Bus), - Une tranche back-office, contenant les briques métier structurantes du Système d'Information. L'objectif est de « décapsuler » les silos étanches et verticaux du SI (progiciels ou applications spécifiques) pour qu'ils offrent désormais des « prises » sous forme de services pour pouvoir recomposer de nouvelles applications de surface plus rapides et plus simples à réaliser en assemblant les services disponibles. Notion importante : l'approche SOA autorise la rupture de technologie (en clair on peut coder son frontal en PHP et appeler un back-office en Java ou en Cobol via des Web Services par exemple). Chaque couche peut être développée dans une technologie différente (on va arrêter les débats stériles pour comparer les filières Java, PHP et Microsoft) puisque maintenant elles peuvent allègrement cohabiter. La règle du jeu : composer et recomposer autour d'un ESB Comme le Web 2.0, l'architecture logicielle suit la tendance sociologique : le recomposé est à le mode. L'idée phare de l'approche SOA est d'assembler des services dédiés, des services partagés et des services techniques pour composer rapidement une application sur mesure. Un point à noter est le nouveau rôle central de l'ESB (Enterprise Service Bus): comme le serveur d'application a remplacé l'OS, l'ESB va remplacer (ou enrichir) progressivement le serveur d'application pour le doter d'un moteur de gestion des échanges, et le plus souvent d'un moteur d'exécution des processus. C'est déjà la nouvelle brique infrastructure de base des architectures logicielles et le futur « centre nerveux » du Système d'Information. Qu'est-ce qu'on gagne : le Graal de la réutilisation L'approche SOA répond enfin à la quête du Graal de l'approche objet, initiée dans les années 90 : on va pouvoir vraiment mutualiser et réutiliser des composants logiciels. On distingue 3 types de services réutilisables : - des services partagés, qui sont exposés par un quartier fonctionnel du Système d'Information (exemple : Facturation) et qui centralisent et mutualisent une fonction métier, - des services techniques, qui permettent de mutualiser une fonction technique transverse (exemples : impression, stockage, GED, sécurité, ...), - des services dédiés, qui sont des services composites créés pour servir un canal ou une application particulière (exemple : l'ensemble des services dédiés de mon extranet client). Le SOA suit le principe de la spécialisation ascendante : les services des couches basses sont communs à l'ensemble du SI, et plus on monte vers les couches hautes, plus les services se spécialisent, jusqu'à la présentation qui est propre à chaque application composite. Le gain principal en développement et en maintenance est de s'appuyer sur des couches communes validées et de ne réaliser que les nouveaux composants vraiment nécessaires au besoin. Dans un monde idéal : tout est service, l'élément de base du mécano On associe trop souvent la SOA au seul Web Service, en fait c'est bien le service qui est le boulon du mécano, c'est lui qui autorise l'assemblage entre deux pièces hétérogènes. Et le service n'est pas forcément Web Service, c'est toute interface permettant de faire communiquer deux applications informatique via un contrat de service. Le critère de choix d'une solution informatique n'est plus seulement sa couverture fonctionnelle (le fameux silo vertical) mais son ouverture et son interopérabilité. Une bonne solution doit exposer les services des fonctions qu'elle rend. La difficulté reste de définir le bon niveau de granularité fonctionnelle ou technique de l'interface exposée par un service, rôle transverse des urbanistes et architectes, dont la SOA annonce le retour en force. Dans la vraie vie : SOA is dead ? Un article désormais fameux a annoncé la mort de l'approche SOA (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html). C'est assez vrai pour la SOA de refonte. La probabilité de voir de grands projets de transformation pour migrer un Système d'Information dans son ensemble vers une cible full SOA est en effet assez faible. L'approche SOA répond par contre parfaitement à des besoins tactiques ou agiles : on peut « rhabiller » les anciennes applications en exposant sous forme de services leurs fonctions et donc adopter une trajectoire de convergence progressive. Attention dans ce cas à la pertinence et l'utilisabilité réelle des services exposés. Beaucoup d'applications back-office ainsi « rhabillées » offrent une couche service inexploitable, car pas à la bonne granularité et exigeant une connaissance trop fine des fonctions exposées. A la décharge également de la SOA, un de ses points faibles est sa gestion des transactions. On ne peut pas enchainer l'appel de deux services en garantissant l'exécution globale (exemple : création de compte puis transaction). Il faut prévoir des services de compensation manuels ou automatisés pour gérer les erreurs. En synthèse, il faut apprendre les règles du jeu, on va tous faire du mécano Ma conviction est qu'on va faire tous faire du mécano à plus ou moins brève échéance, c'est une lame de fond portée par un nouveau modèle. L'approche SOA est la 4ème génération du modèle informatique après Mainframes, Client/Serveur et Client Web. L'application composite va s'imposer, Apple est en train de le démontrer avec l'iPhone. La SOA tactique, agile, progressive et intelligente va régner en maître, pour la plus grande joie des architectes et urbanistes.
Article rédigé par
Rémi Moebs, Senior Manager chez Sopra Group Atlantique
Responsable de la cellule « Architecture et Solutions Collaboratives » au sein de la Division Business Consulting de Sopra Group Atlantique
Consultant et agitateur technologique depuis 12 ans sur les sujets Web, Web 2.0, KM et collaboratif, e-commerce, Architecture agiles et distribuées.
Commentaire
INFORMATION
Vous devez être connecté à votre compte CIO pour poster un commentaire.
Cliquez ici pour vous connecter
Pas encore inscrit ? s'inscrire