Dimanche 11 décembre 2005
Furtivement présenté dans un livre blanc d’IBM, le modèle de programmation SCA (Service Component Architecture), acquiert aujourd’hui pignon sur rue avec le support très officiellement annoncé des éditeurs et sociétés de conseil BEA, Oracle, Siebel, Sybase, Iona et Interface21. Microsoft, qui manque à cet appel, a, quant à lui, sa propre décoction développée en interne, Indigo, poétiquement rebaptisée depuis peu Windows Communication Foundation.
Pour les briscards de l’orienté objet, vétérans des guerres picrocholines du siècle dernier autour des modèles objet – et nombreuses furent-elles, illustrées par les acronymes oubliés et soldats inconnus dans VMS, COM (Component ou Common Object Model, déjà), OLE, DCOM, ORB, IIOP, Corba, OpenDoc et autres, auxquels tous ont contribué de HP, Apple, Sun, Microsoft, IBM jusqu’aux plus petites startup – il est particulièrement désespérant de constater qu’on s’interroge encore sur les « foundations » de l’interopérabilité et de l’échange de données ! Les composants logiciels sont successivement devenus la tarte à la crème pour les programmeurs, puis les concepteurs, et les architectes et urbanistes des systèmes d’information. Faut-il encore que l’on invente une énième surcouche aux velléités unificatrices, prouvant au passage que les effets oratoires antérieurs sur l’interopérabilité n’ont évidemment rien résolu : le problème a la vie dure !
La question, vieille comme le temps, est celle de la division du tout en fragments plus compréhensibles et de la reconstitution dudit tout (ou d’autres, similaires) à partir de ceux-ci. Quand les composants étaient des bibliothèques de programmation – le vocabulaire trahit ici l’intention – on s’intéressait à l’éditeur de liens. Quand les programmes ont découvert le réseau local et les modèles de threads, on a sanctifié le RPC, le Remote Procedure Call. Les objets se sont ensuite glissés dans nos langages de programmation, le C devenant « plus-plus » ou « Objective », puis carrément « sharp », SmallTalk, source d’inspiration de nombreux successeurs, Eiffel, détenteur des nouvelles tables de la loi, et, Internet emportant tout dans son succès, Java et tous les langages de script, devenus à leur tour orientés objet, comme naguère l’objet vint à Basic et le fit « Visual ».
Dans cette évolution, il devenait alors urgent que la communication entre programmes, devenus entre-temps objets, soit, elle aussi, drapée de l’orientation objet dans un souci affiché d’interopérabilité (déjà !). Suit donc le long épisode de la transformation chez Microsoft d’OLE en COM, à l’occasion du passage de Windows de l’architecture de processeur 16 bits à celle des processeurs 32 bits, puis en DCOM pour ne pas apparaître comme à l’arrière-garde face au reste de l’industrie, conspirant dans le nouvellement créé Object Management Group (OMG), à la construction de la machine de guerre Corba (Common Object Request Broker Architecture). Eux-mêmes d’ailleurs faillirent se prendre les pieds dans le proverbial tapis, puisque les implémentations mêmes de Corba présentant certaines (mais persistantes) incompatibilités, l’OMG eut à spécifier dans la précipitation des normes d’interopérabilité (IIOP : Internet Inter-ORB Protocol, fascinant !) entre ORB tous standards et tous incompatibles – ceci sur fond de montée en puissance du protocole IP dans les domaines des réseaux et, bien sûr, d’émergence d’Internet.
Dans ce contexte historique, il est proprement inconcevable (les outils ne vous laissent plus faire !) de développer une application sans se préoccuper d’objets et, dans le même esprit, de leur version moderne, les composants logiciels. Les frameworks à composant sont le nec plus ultra de l’outillage du développeur qui se respecte. Plus personne ne se souvient de Taligent, mais aujourd’hui .NET de Microsoft et les serveurs d’applications J2EE deviennent des commodités (pensez donc, il y en a même en Open Source – et plusieurs encore !) et les outils de développement présupposent déjà l’idée de la fragmentation de l’application en composants.
Reste qu’avec le succès du Web, on a peut-être la chance de voir l’autre face de la médaille, le problème de la « reconstitution »de l’application par l’assemblage de ses fragments enfin résolus. Les protocoles rendus populaires par le Web, http et autres, sont banalisés dans l’entreprise et hors de l’entreprise, fournissant à bon compte une infrastructure gratuite, étendue et continuant à s’étendre de jour en jour, de manipulation simple. De là à l’enrôler comme « colle à composants » il n’y eut qu’un pas vite franchi par éditeurs et utilisateurs. C’est la base de la SOA, la Service Oriented Architecture, qui remet au goût du jour l’inépuisable notion de composant. Le composant logiciel devient ici « service », exécuté sur un nœud du réseau, communiquant avec d’autres services via ce même réseau et les protocoles Internet. On a encore grimpé d’un échelon sur la grande échelle dont l’extrémité est enfouie, tout en bas à perte de vue, dans un éditeur de liens.
Le SCA ou Indigo vise, comme leurs prédécesseurs dans cette ascension, à rendre interopérables les diverses implémentations des composants logiciels considérés comme des services. Le site d’IBM sur WebSphere, par exemple, en est presque caricatural : on y trouve une recension quasi encyclopédique de FAQ de la forme « Comment faire migrer un XXX vers le modèle de programmation SCA ? », dans lequel on remplace, au choix, XXX par votre composant habituel favori (EJB, service Web JMS, SOAP/HTTP, J2C-IMS, J2C-CICS, J2C-HOD, WSIF, etc.). On change d’acronyme et on recommence !
Tirons en les conclusions, temporaires sans doute, que le problème de l’interopérabilité est exacerbé plutôt que résolu par le développement de l’architecture SOA, mais qu’il n’est ni nouveau ni inconnu, loin de là. (Par exemple, et loin de moi l’idée d’engager la polémique, mais ne faudrait-il pas déjà une nouvelle surcouche d’interopérabilité pour qu’un service Indigo interopère avec un service SCA et vice-verSCA ? ISCA, Interoperable Service Component Architecture, peut-être – vos suggestions « acronymiques » sont les bienvenues !) Enfin notons quand même que ces nouveaux efforts de formalisation et de spécification arrivent bien à point de chez Microsoft et de chez IBM, au moment où les Web Services ont perdu l’attention de l’industrie (et commencent même à en attirer les critiques) au profit de Google qui a légitimé le modèle AJAX des « mashups » comme altermondialisation des services Web et des composants logiciels.
