|
|
Que recouvre la notion de SOA ?
Conceptualisée par le Gartner Group, la notion de SOA (Service Oriented Architecture - ou architecture orientée services) renvoie à une nouvelle manière d'intégrer et de manipuler les différentes briques et composants applicatifs d'un système informatique (comptabilité, gestion de la relation client, production, etc.) et de gérer les liens qu'ils entretiennent.
Comme son nom l'indique, cette approche repose sur la réorganisation des applications en ensembles fonctionnels appelés services. Un service n'est autre qu'une application exposée par le biais d'une interface XML standard (langages SOAP/WSDL), connue sous le nom de Web Services, couches d'invocation compréhensibles potentiellement par l'ensemble des systèmes en présence, pour peu qu'elles intègrent le module d'interprétation nécessaire. Au sein d'un tel environnement, des services (dits "producteurs") sont ainsi exposés à d'autres services (dits "consommateurs").
Comment fonctionne une architecture de services Web ?
Une architecture de services Web consiste à organiser les habilitations d'invocation entre les composants précédemment cités. Mais également à agencer les services Web au sein de processus métier (gestion des commandes, etc.) eux-même opérables sous forme de services Web par d'autres systèmes (facturation, systèmes clients, etc.). Une méthode d'encapsulation que permet de mettre en oeuvre certains standards XML plus récents (tels BPEL).
Sur ce dernier point, le SOA ne réinvente pas tout. Il s'appuie sur des méthodes d'orchestration déjà bien connues - telle la gestion de règles métier - pour assurer le routage des flux et des requêtes vers le bon service de destination en fonction des demandes.
Quel est l'apport d'une telle architecture ?
Par son caractère standard, l'approche SOA contribue à améliorer la rapidité ainsi que la productivité des développements. Un composant exposé sous forme de Web Services pouvant être réutilisé à loisir par d'autres applications. Exemple type : les dispositifs de requêtage et d'inscription au sein d'un annuaire d'entreprise, solution classiquement conçue pour gérer les droits d'accès aux applications en stockant les profils utilisateur. Une fois publiées par le biais de Web Services, ces fonctions peuvent être aisément intégrées aux différentes briques du SI sans que le développement de connecteurs spécifiques au cas par cas ne soit nécessaire.
Autre apport : la technologie des Web Services va jusqu'à intégrer une démarche de "fourniture de services". Une logique qui, au-delà de services techniques d'intégration, renvoie à la publication de composants sous la forme de "services métier" délivrés à des applicatifs clients (internes ou externes), avec à la clé l'ensemble des notions sous-jacentes : contrat de service, niveau de service, etc. Pour être appliquée, cette philosophie passe par la mise en place d'annuaires de Web Services incluant l'ensemble des éléments nécessaires à la consommation de ces derniers (adresses, droits d'accès, conditions d'utilisation, etc.).
Les solutions de SOA sont-elles mures ?
Aujourd'hui, la plupart des serveurs d'intégration (EAI) et des plates-formes applicatives savent exécuter les interfaces en mode Web Services. Ce qui leur permet par conséquent de supporter un premier niveau d'architectures de type SOA, c'est-à-dire un ensemble de Web Services distribués dialoguant entre eux. Certaines offres vont plus loin en incluant l'orchestration de processus standardisés (via BPEL).
Des pure-players se sont également positionnés sur ce nouveau segment, en apportant tout ou partie d'une architecture de SOA (gestion de processus, supervision, etc.). Certains éditeurs, tels Fiorano ou Sonic Software, allant jusqu'à fournir des bus de services complet, ou ESB (pour Enterprise
Service Bus), conçus pour orchestrer des services sur la base des standards
du domaine, BPEL notamment.
Quels sont les principaux obstacles à la mise en oeuvre d'une architecture SOA ?
Le premier est technique. Certains anciens systèmes demeurent difficilement compatibles avec les Web Services, et donc ne peuvent s'inscrire dans une telle architecture. Ce qui s'explique généralement par leur caractère trop peu fragmenté. Un élément qui rend en effet les composants difficiles à publier sous forme de services, ceux-ci étant par nature granulaires. Autre point : même si les standards des services Web (SOAP/WSDL) et de l'orchestration orientée services (BPEL) commencent à se généraliser, les
solutions d'intégration doivent encore trop souvent proposer des langages complémentaires pour la
gestion des transactions ou de la sécurité. Bref, le modèle reste
encore assez loin de la palette fonctionnelle que propose, par exemple, un bus CORBA, sorte de SOA pour le monde des serveurs d'applications J2EE... Le chantier de standardisation est loin d'être achevé.
Le second obstacle à l'émergence des SOA est méthodologique. Alors que les différentes briques de l'architecture se précisent de jour en jour, il existe encore assez peu de méthodes couvrant l'élaboration et le déploiement de celle-ci, sans doute par manque de retours d'expérience. Pour l'heure, quelques sociétés de services proposent des démarches dans ce domaine. Parmi elles, on compte notamment Capgemini, Unilog ou encore Dreamsoft.
| |
:: Les principaux fournisseurs ::
|
| |
|
Editeurs de solutions de SOA
|
Editeurs d' EAI
|
Editeurs de plates-formes applicative
|
|
Fiorano,
Sonic Software,
Amberpoint,
CapeClear,
Collaxa,
Oblix.
|
SeeBeyond,
Tibco,
webMethods.
|
BEA,
IBM,
Sun,
Microsoft,
Oracle.
|
| |
:: Les indicateurs-clés ::
|
| |
|
950
|
millions de dollars pour le marché mondial des Web Services en 2004. En 2008, il devrait atteindre 6,2 milliards de dollars. (Source Radicati Group) |
|
60%
|
des entreprises opéreront leurs applications métiers par le biais d'une architecture SOA d'ici 2008 (Gartner). |
|
|
Dossier 
