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.

• SOA : des architectures pas conçues pour les métiers
• Imposer des outils de gouvernance
• Découper et calibrer correctement les services
• Le long chemin vers la normalisation de l'architecture
• Des plates-formes intégrées encore jeunes
• Les spécialistes de l'infrastructure visent les métiers avec SOA
• Les éditeurs de plates-formes cohabitent avec les spécialistes
• Yves Caseau (Bouygues Télécom) : ' éditeurs de solutions, adressez-vous mieux au métier '

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 ?"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 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 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. '