nos newsletters
Lisez 01Business pour 6,54 € / n°
Des plates-formes intégrées encore jeunes
Les suites SOA des géants de l'infrastructure logicielle restent difficiles à différencier. Certains de leur modules affichent une trop forte dépendance les uns avec les autres.
sommaire
Voir tout le sommaire 
L'ESB (Enterprise Service Bus) pour les échanges et les transformations de données, le BPM (Business Process Management) pour l'orchestration de processus, le BAM (Business Activity Monitoring, supervision des
processus) pour leur suivi, les référentiels SOA pour les règles de gestion des services, les frontaux web 2.0 (portail, serveur de mashup, blog, wiki...) pour leur exposition... Depuis un peu plus d'un an, les géants de
l'infrastructure s'emploient à bâtir des plates-formes SOA ' tout-intégré ' à coup d'acquisitions ou de partenariats. BEA, IBM, Microsoft, Oracle, Software AG/Webmethods, Tibco et d'ici à
quelques semaines Red Hat/JBoss en sont les porteurs.
Les promesses de ces suites SOA sont de deux ordres : assurer une supervision de bout en bout des différentes briques qui les composent et garantir la parfaite interaction des unes avec les autres. Sur le papier donc, les
plates-formes affichent les mêmes composants, et les mêmes promesses. Commentalors les différencier ? Question qui est d'autant plus délicate que les retours d'expériences ne sont pas légion : ' Les
rares déploiements ne font intervenir que deux ou trois composants de la suite. Et ils ne concernent souvent qu'un seul processus pilote ', explique William Kinfouossia, directeur général d'Inexware.
Mêmes rares, ces mises en ?"uvre révèlent quelques écueils, souvent liés à l'incapacité des modules à fonctionner isolément. C'est le cas avec la plate-forme d'IBM, l'une des plus répandues sur le
marché : ' Quand IBM a dû dissocier son Process Server de son ESB, la peinture n'était pas sèche ', explique Mariano Boni, directeur technique de Dreamsoft (groupe Solucom). Le design de
flux de données, jusque-là conçu dans l'environnement de BPM, devenait une opération complexe lorsqu'il s'effectuait depuis son ESB. Questionnements identiques chez BEA : la version de son BPM (issue du rachat de Fuego) diffère
selon qu'il fonctionne dans la pile SOA de l'éditeur ou isolément. ' La version qui a été intégrée au bus de BEA n'a pas les mêmes outils de modélisation ou de déploiement et, surtout, elle était émaillée
de bugs ' rapporte Mariano Boni. Quant à Oracle, son ' modeleur ' de BPM aurait du mal à parler avec son ESB...
De multiples environnements de développement
Autre point susceptible de différencier ces suites : l'interaction des différents environnements de développement. Car les plates-formes SOA en comptent plusieurs. Deux chez Microsoft (Biztalk et Visual Studio), quatre
chez IBM. Ce dernier dispose d'un atelier pour le design de processus, la modélisation du BPM, le développement des composants métier et le développement classique. Et chacun d'eux s'adresse à des profils différents
(fonctionnel, urbaniste, développeur...). ' Idéalement, ces ateliers de réalisation gagneraient à être rationalisés, ou au moins à être parfaitement intégrés les uns aux autres ', explique Marc
Boullier, directeur technique chez Vistali, qui souligne l'avance de BEA et de Tibco sur ces points. A terme, ces environnements de développement devront également partager les annuaires et les référentiels de services.
Mais au-delà des critiques ainsi ciblées, d'autres portent sur les soubassements mêmes de ces plates-formes. A savoir leur alignement sur le protocole Soap et ses spécifications WSDL/WS-*. Autrement dit, à leur alignement sur
les services web. ' Ces spécifications sont lourdes, complexes, et elles sont marquées par des problèmes d'interopérabilité ', lance Philippe Mougin consultant chez Octo Technologies. Il regrette
que les spécialistes des plates-formes SOA limitent HTTP à des fonctions de transport sans exploiter le potentiel de ses couches hautes. Des couches qui couvrent pourtant bien des aspects des échanges interapplicatifs tels que la gestion des
erreurs ou des flux sécurisés. ' Ces fonctions ont été réinventées à travers des spécifications WS-*, elles-mêmes encore peu déployées. ' Cette émancipation de Soap, que certains clients SOA commencent
à appeler de leurs v?"ux, tient pour beaucoup à l'avènement de services web, proposés par Amazon, Yahoo ! ou Google, qui transportent XML directement sur HTTP, sans encapsulation Soap (Simple Access Object Protocol, protocole de
transmission de messages).
2 questions à... : Didier Mamma, directeur général de Progress
Comment résister face aux piles SOA des géants de l'infrastructure ?
' Ces offres restent perfectibles dans les architectures fortement distribuées. Dans le cas, par exemple, d'un siège d'entreprise qui doit échanger des données avec ses magasins, celles-ci
reposent en effet sur un serveur d'applications. Cette architecture centralisée va alors générer beaucoup de trafic inutile. Le bus gagnerait donc à être totalement distribué et permettre que deux sites interagissent sans nécessairement en
référer à un chef d'orchestre. Ce sont donc sur ces enjeux d'architecture que nous nous différencions des géants de l'infrastructure. '
Peut-on fournir des infrastructures SOA sans proposer de frontaux utilisateurs ?
' L'enjeu des SOA n'est pas sur l'exposition de services mais sur l'interaction des objets de bas niveau. Ce serait mettre la charrue avant les b?"ufs. Les priorités
concernent l'orchestration de services ou la recherche d'impact entre services. '
à lire aussi
SUR LES MÊMES THÈMES 
