|
| |
|
|
 |
| Déployer une architecture orientée services en cinq étapes |
| Derrière les environnements SOA, la possibilité de mettre en place des processus métier dynamiques, recomposables en fonction des besoins de l'entreprise. Marche à suivre
(30/08/2005) |
|
Une architecture orientée services (SOA) renvoie à un modèle d'intégration d'applications à travers lequel les fonctions assemblées (comptables, de production, etc.) ne seraient plus considérées uniquement comme des composants techniques formant un processus métier ou une nouvelle application statique, mais plutôt comme des composants réutilisables d'un processus à l'autre, de façon dynamique, et recomposables entre eux.
Une caractéristique permise par les technologies XML sous-jacentes au SOA (SOAP et WSDL), autrement appelées Web Services, qui fournissent aux systèmes en présence une bibliothèque de langages universels pour dialoguer, quelle que soit leur origine technologique (Windows, J2EE, mainframe, etc.).
1) Opter pour une démarche progressive
Un système d'information peut difficilement passer sans transition d'un modèle d'intégration d'ancienne génération, orienté connecteurs synchrones et EAI (intégration d'applications d'entreprise) ou traitements par lots (batch), à une architecture orientée services. "Il est conseillé de mettre en oeuvre une démarche d'urbanisation progressive, et commencer petit tout en ayant dans l'esprit d'aller plus loin ensuite", souligne Michaël Tartar, Consultant manager chez BearingPoint.
Et Mariano Boni, directeur
technique de Dreamsoft (Groupe SoluCom), de renchérir : "Une politique itérative est d'autant plus importante que les équipes techniques et la maîtrise d'ouvrage métier (MOA) doivent disposer d'un certain degré de maturité pour se lancer dans le projet. Un tel chantier nécessite en effet la maîtrise d'outils et de méthodologies particulières au sein de la DSI, et la capacité des MOA d'exprimer leurs besoins sous forme de processus de services".
2) Lancer d'abord un processus
Il est recommandé de débuter par un premier processus, impliquant dans la mesure du possible plusieurs départements. "Mais attention, plus il y a d'acteurs dans la boucle, plus les contraintes opérationnelles seront fortes, car il faudra obtenir de chaque responsable les droits d'accès à son système, ce qui peut provoquer des résistances", prévient Mariano Boni.
L'intervention d'une cellule d'urbanisation est ici intéressant pour effectuer les arbitrages managériaux. Une équipe qui aura également pour but de garantir la capacité de réutilisation des interfaces de services créées.
Classiquement, cet applicatif représente pour la Direction des systèmes d'information le moyen de constituer un premier retour d'expérience, qui lui permettra ensuite de convaincre plus facilement les décideurs quant à l'intérêt du SOA et de sa généralisation. "Idéalement, il peut s'agir d'un processus à forte valeur ajoutée, combinant trois à quatre services Web, la gestion de la vente d'un nouveau produit par exemple", note Mariano Boni.
3) Commencer par déployer un outil Open Source
De nombreux produits du marché sont adaptés au support d'une architecture de SOA. On les regroupe sous l'expression Bus de services d'entreprise (ESB).
Mais le choix de solutions propriétaires est une démarche lourde en termes budgétaires, et dont le cycle de vie est peu adapté aux conditions de livraison des MOA, qui demandent à la DSI une grande réactivité dans la foulée de l'expression de besoins. D'où la pertinence d'opter pour un outil Open Source, du moins lors des premiers déploiements.
| "Une application Open Source pour implémenter ses premiers processus" |
"Une application Open Source permet d'implémenter ses premiers processus à moindre frais au sein d'une technologie non-engageante, à la différence d'un prototype réalisé avec un éditeur", commente Michaël Tartar.
"L'idée est d'aller vite, tout en donnant à la direction informatique le temps de choisir une plate-forme plus pérenne et de se familiariser avec le nouvel environnement. Les premiers processus élaborés pourront en outre être exploités pour tester les produits sélectionnés lors de l'appel d'offres."
4) Qualifier la couche technique
La mise en oeuvre d'une architecture de SOA engendre un certain nombre de choix technologiques. "Il faut en premier lieu bien spécifier le vocabulaire (XML) métier exploité au sein des messages pour qualifier les différents types de données échangés (niveau de stocks, prix, gamme, etc.)", indique Mariano Boni, avant d'insister : "il est fondamental de prendre garde au degré de granularité de l'architecture.
S'il est trop grand, on risque de se retrouver en présence d'une multitude de services difficilement réutilisables. Si il est trop faible, les messages peuvent devenir trop volumineux et par conséquent ingérables, car couvrant des champs trop larges (la relation client, etc.)."
5) Assurer la sécurité de l'infrastructure
Afin d'assurer le bon acheminement des requêtes nécessaires aux processus, un service Web métier peut inclure plusieurs services techniques, gérant par exemple la persistance des données ou assurant des points de validation. Reste que certains flux ne pourront pas être mis en oeuvre sous forme de Web Services, leur volumétrie et/ou leur degré de sollicitation nécessitant pour fonctionner les garanties offertes par des mécanismes de plus bas niveau - de type serveur d'applications.
"Quant à la gestion de la sécurité des accès, elle dépendra du degré de confidentialité que l'on souhaite attribuer à l'infrastructure et aux données échangées" estime Michaël Tartar chez BearingPoint. "Là encore, on peut préférer au SOA une solution de plus bas niveau, plus sécurisante, ou encore des solutions tierces - telles que les réseaux privés virtuels qui isolent les flux de messages du reste du réseau.
Notez que le SOA dispose également d'outils adaptés, tels que les pare feu XML et les langages WS-Security, qui permettent de chiffrer jusqu'au contenu des messages échangés."
|
|
|
|
Dossier 
