Chose promise, chose due. Les éditeurs de logiciels qui s'étaient réunis et avaient annoncé en décembre 2005 vouloir plancher sur un modèle de programmation standard pour les architectures orientées services (SOA) viennent non seulement de remettre leur copie, SCA v1.0, mais annoncent en outre leur intention de porter le tout à l'Oasis, afin que cette spécification devienne vraiment un standard. SCA (Service component architecture) a été initié par plusieurs éditeurs impliqués dans les SOA, tels IBM, Oracle, SAP, Iona, Xcalia... Ils ont été rejoints par d'autres acteurs, dont Sun (les tractations ont été délicates) et Red Hat (alors qu'à l'époque, Marc Fleury, le patron de JBoss, avait vivement critiqué l'initiative), gonflant le nombre à 18. Leur but était d'établir un modèle de référence, afin de faciliter l'intégration entre des produits de différentes provenances. Il y a en effet pléthore de petites spécifications standards pour réaliser des architectures orientées services, et rien ne dit que ces spécifications et les méthodes pour les employer soient compatibles entre elles. Dans le même ordre d'idées, le groupe, qui s'est appelé Osoa (pour Open SOA), s'est aussi attelé à SDO (Service data object), un moyen d'exploiter de façon homogène des données provenant de sources diverses. Des implémentations ont été proposées pour C et Cobol (l'Osoa continuera de plancher dessus), et définies pour C++, PHP et Java. Cette dernière sera soumise au JCP, l'organisme qui gère les spécifications liées à Java, tandis que la version C++ sera soumise à l'Oasis. L'Oasis a déjà planifié la création de plusieurs comités techniques chargés de ces questions ; ils devraient débuter leurs travaux en juin. Un cadre de référence plus large que la pléthore de spécifications WS-* La spécification SCA prend en compte le support du langage pour l'exécution de processus BPEL (Business process execution language), le gestionnaire de cinématique en Java Spring, ainsi que deux langages : Java et C++. Le travail sur C++ s'explique probablement par le fait que l'Osoa voulait éviter d'apparaître comme un organisme strictement orienté Java, donc en réaction face à Microsoft. Vice-président pour les standards de l'industrie chez SAP, Michael Bechauf indique aussi que SCA comporte un modèle d'assemblage décrivant la façon dont les différentes briques SOA doivent interagir, afin que les développeurs, architectes ou autres personnes intervenant sur des briques individuelles s'accordent sur un modèle cohérent. Les premières annonces sur SCA avaient suscité beaucoup d'interrogations. Un standard de plus, qui plus est défini par des industriels et non par un organisme de standardisation, pouvait rendre le tableau de la SOA encore plus complexe à décrypter. Mais, comme le souligne Mariano Boni, directeur technique de la SSII et société de conseil Dreamsoft (groupe Solucom), « chacun cherche à faire un peu plus que le standard, du 'BPEL++', ce qui se traduit par du '--' par rapport à la standardisation. La démarche SCA est donc très intéressante, elle donne une dimension de composant d'architecture de services. Et le fait que cela entre à l'Oasis lui donnera probablement un cadre plus clair ». Avis partagé par Marc Boullier, son homologue chez le concurrent Vistali. « A la différence de Microsoft, qui s'appuie sur une multitude de standards Ws-*, SCA offre un cadre plus global, qui améliore la lisibilité. C'est en outre une garantie de compatibilité. » Et la soumission à l'Oasis est bien un gage de maturité, « un signe de stabilisation, qui donne un niveau de confiance plus important, et peut amener à des recommandations plus favorables sur le terrain ». Face à des projets de SOA qui se multiplient dans une même entreprise, explique Marc Boullier, « il faut maîtriser la manière dont les architectes vont travailler, il faut donc un cadre de référence simple et lisible ». Seule inquiétude, formulée par Mariano Boni : que cette soumission à l'Oasis ne se traduise par un ralentissement des travaux sur le sujet.