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 inter­action des unes avec les autres. Sur le papier donc, les plates-formes affichent les mêmes composants, et les mêmes promesses. Comment­alors 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 oeuvre 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...

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 limi­tent 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 voeux, 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).