L'architecture SCA (Service Component Architecture) reste une initiative démocratisée relativement récemment même si la version 1.0 a été publiée il y a plus de deux ans maintenant. L'annonce d'Oracle Fusion 11G a récemment rappelé son support par différents grands éditeurs. Il n'en reste pas moins que son périmètre d'utilisation n'est pas forcément évident, d'autant plus qu'il s'agit d'un des nombreux sigles associés à SOA : WS-*, BPEL, JBI, SDO... Nous allons tâcher au sein de cet article de clarifier les potentialités de cette norme et de proposer des contextes qui me semblent propices pour en tirer profit.
Cette norme est désormais portée par le consortium OASIS. L'architecture SCA se base sur la notion de composants indépendants à la fois du langage et de la technologie. Son objectif est de standardiser la notion d'injection et d'interface pour tous les middlewares et tous les langages. Cela doit permettre d'écrire des composants en Java, C++, Cobol, BPEL etc. et de les interconnecter plus simplement qu'en combinant l'ensemble des technologies de web services nécessaires pour arriver au même résultat. Dans l'optique de cette norme, pour être efficace, une architecture SOA nécessite d'être implémentée à base de composants configurables. Les services web deviennent alors les interfaces de ces composants SCA. Ceux-ci comportent dans la terminologie de la norme :
. SCA va de paire avec la norme Service Data Object qui vise à fournir un accès à toutes les sources de données pour tous les langages. SDO permet de définir un ensemble de données (un DataSet) que l'on peut extraire, modifier, échanger - par exemple entre composants SCA - et redonner à la source de données pour reporter les modifications.
Aujourd'hui en 2009, on cherche à l'intérieur d'une application à réutiliser du code par assemblage de classes, utilisation de frameworks. Les SI sont moins en silot que par le passé : différentes applications utilisent un service web que propose une application dépositaire d'une fonction partagée. Aujourd'hui cependant chaque application utilise un nombre modéré de services externes, réellement partagés avec d'autres applications. L'objectif de SCA - faciliter la réutilisation des services en les combinant - trouve peu d'écho aujourd'hui ou le nombre de services utilisés reste modéré.
Alors existe-t-il des limitations que SCA permettrait de résoudre? Nous pensons que les difficultés d'assemblage de services, la complexité liés aux nombreuses normes SOA et de couplage au mode de transport peuvent nécessiter une réponse globale comme SCA si une application est réalisée majoritairement par assemblage de briques métier à forte granularité et développées par des équipes différentes. Lors de l'université du SI, le rendez-vous annuel des geeks et des boss organisé par Octo Technology, Jean-René Lyon a présenté au cours de sa session The times they are a changing la vision d'une informatique différente où les applications seraient construites à 80% à partir de fondations métier communes assemblées (à partir de 11 min. 30 dans la vidéo). Dans l'optique d'une informatique basée ainsi sur la réutilisation massive de très nombreux composants métiers, des limitations pourraient apparaître au niveau de l'assemblage et SCA pourrait être une réponse unificatrice. Cependant, le développement informatique actuel ne fonctionne pas (encore ?) de cette façon.
Aujourd'hui, le SI reste composé d'applications dialoguant entre elles via des services. L'application est homogène, développée par une seule équipe. Sa modularité interne doit rester souple, simple à mettre en oeuvre, car la priorité reste la livraison de l'application complète et non la réutilisation. Le framework Spring de par sa simplicité est devenu le standard de fait pour organiser la modularité à l'intérieur d'une application. Le dialogue avec le monde extérieur, exposition et consommation de services partagés, écrits dans des technologies différentes, reste d'un autre domaine : celui de l'intégration. Le coût du dialogue avec les autres équipes (dans quel élément du WSDL se trouve la date valeur?), la coordination des cycles de vie (montée de version, compatibilité), les soucis de disponibilité dans le cas d'un service distant font que le SI n'est pas une agrégation homogène de composants mais plutôt une intégration de différentes applications. De très nombreuses solutions existent. Là encore SCA n'apporte rien de nouveau face à l'intégration par injection des piles web services comme CXF dans Spring. Aujourd'hui SCA est mis en avant dans les solutions des éditeurs d'EAI ou d'ESB : cela structure ces produits et cela assied leur image de pérennité. Cependant dans la pratique deux EAI implémentant SCA comme Oracle Fusion Middleware ou Tibco ActiveMatrix ne peuvent pas échanger des composants SCA développés l'un avec l'autre. L'accès depuis l'un de ces produits à un composant SCA exposé par une application nécessitera un paramétrage équivalent à un appel de web service. Aujourd'hui SCA apparaît plus comme un standard de plus dont la valeur ajoutée reste faible par rapport aux outils déjà en place.
Aujourd'hui les problématiques techniques traitées par SCA sont bien connues et peuvent être gérées de différentes manières, SCA -étant l'une d'entre elle. Aboutir à une architecture de fondations telle que décrite par Jean René Lyon nécessite de résoudre d'autres enjeux primordiaux préalablement à une n ième standardisation de packaging
A mon sens, aujourd'hui, l'architecture SOA ne souffre pas de difficultés techniques mais avant tout de difficultés méthodologiques. Lorsque celles-ci seront levées petit à petit, la quantité de code réutilisé pourra croître. Si cela doit passer par une plus forte agrégation de services, ou par plus de paramétrage (évolution du service vers le composant), SCA pourrait avoir sa place mais la concurrence sera forte avec les technologies en place. Pour conclure nous vous donnerons trois références qui adressent ces difficultés méthodologiques
Par Dominique Jocal et Marc Bojoly