|
| |
|
|
 |
| Architecture orientée services : SODA vs SOBA |
| Derrière l'architecture induite par l'arrivée des Web Services se dessinent deux grandes approches : l'une s'enracine dans une vision plus technique, l'autre dans une logique 100% métier.
(20/09/2006) |
|
> Comment définir SODA ?
SODA (pour Développement d'applications orienté service) représente une approche du développement logiciel consistant à construire des applications par l'assemblage de composants invoqués sous forme de services Web. Ici, on entend par services des interfaces standardisées reposant sur plusieurs spécifications (en XML). L'objectif : aboutir à un système d'information basé sur une architecture orientée services (SOA).
Les spécifications relatives aux services Web permettent de gérer à la fois les appels de composants en provenance de systèmes hétérogènes (via les langages SOAP/WSDL...), mais également de les faire collaborer -par le biais d'un langage comme BPEL- au sein d'une application elle même invocable sous forme de service. Elles recouvrent ainsi l'ensemble de l'infrastructure XML nécessaire au développement d'applications orienté service.
> Quels sont les avantages d'une telle approche ?
La plupart des experts du sujet s'accordent à dire que le développement orienté services est synonyme de productivité. Plus besoin en effet de reprogrammer une fonction pour chaque application élaborée. En s'appuyant sur cette technologie, il est en effet possible de faire appel à des composants existants, et de les réexploiter au sein d'un nouveau développement.
Une caractéristique qui induit d'autres avantages intéressants : la capacité offerte par la SOA en matière d'intégration et de synchronisation de systèmes au sein des nouvelles applications, peut contribuer à éviter le transfert de données en gros volumes (batch, etc.) nécessaire dans les architectures d'ancienne génération, mais aussi permettre l'exploitation d'applications plus ancienne sans avoir à les remplacer ou les modifier - pour peu qu'elles soient compatibles avec les interfaces XML évoquées ci-dessus.
> Quelle différence avec SOBA ?
Là où SODA désigne le travail de construction d'une architecture de services, sans faire de différence entre services techniques, fonctionnels et métiers, SOBA (pour Application métier orientée services) renvoie au modèle d'urbanisation métier induit par cette architecture. Il fait donc appel au développement de type SODA pour exister, et supporter des façades du SI par grands métiers de l'entreprise.
| SOBA : le BPM des Web Services |
Derrière cette logique : il s'agit de modéliser les grandes fonctions de l'entreprise (fonctions de commande, de gestion des stocks, d'achats, etc.) et de les regrouper par métiers, mais aussi dessiner les liens métier qu'elles entretiennent au niveau transverse. En d'autres termes, SODA est à l'EAI traditionnel (intégration d'applications d'entreprise), ce que SOBA est à la gestion des processus métier (BPM).
> Qu'est-ce que SOBA apporte de plus comparé au BPM traditionnel ?
Si le travail de développement a été bien réalisé et les services techniques et fonctionnels correctement définis et répartis, l'approche SOBA doit permettre de s'acheminer vers un système d'information agile, capable de répondre rapidement aux évolutions stratégiques d'une entreprise (rachats d'entreprise, lancement de nouvelles activités, etc.). Grâce à la démarche SOBA, les processus métier sont en effet évolutifs et recomposables à loisir tout en pouvant s'intégrer à d'autres systèmes.
> Et les outils ?
Sun, Oracle, Microsoft, BEA, IBM, etc. La plupart des grands éditeurs de solutions d'infrastructure fournissent des solutions de développement et de déploiement pour supporter des architectures de services en se plaçant dans une approche de type SODA.
Quelques éditeurs, plutôt pure player des ESB (bus de services d'entreprise), apportent une couche basée sur des vocabulaires métiers, conçue pour décrire et structurer les processus métier (RosettaNet, ebXML, etc.). Un environnement qui leur permet d'accompagner le déploiement de projet SOBA. C'est le cas notamment de webMethods, ou encore MetaStorm. Plus récemment, on a observé des sociétés de conseil développer une expertise sur ce terrain, comme Accenture (voir l'article du 25/07/2006).
Questions & réponses réalisé suite à un entretien avec Marc Boulier, directeur technique de Vistali.
|
|
|
|
Dossier 
