Introduction à SCA (Service Component Architecture)

SCA (Service Componant Architecture)[1] est un ensemble de spécifications visant à simplifier la création et la composition de services (indépendamment de leur implémentation) dans le cadre d’Architectures Orientées Service (SOA).

Cette spécification était jusqu’ici portée par l’OSOA (Open Service Oriented Architecture), également à l’initiative de SDO (Service Data Objects), qui a annoncé le 21 mars dernier la version 1.0 de la spécification et sa soumission à l’OASIS pour standardisation[2].

Au-delà des guerres de clochers[3] autour de SCA, cette double annonce est l’occasion de revenir sur cette spécification.

SCA propose donc un modèle de programmation pour la construction d’applications à base de composants suivant le paradigme SOA. Ce modèle se base notamment sur l’idée qu’un service de niveau N se construit par assemblage / agrégation / orchestration de services de niveau N-1 ou N (Et ce quelque soit la hiérarchisation choisie. Par exemple : Services organisationnels, Services métiers, Services techniques).

A ce titre, SCA fournit deux niveaux de modèle :

• Un modèle d’implémentation : Construire des composants qui fournissent et consomment des services ;
• Un modèle d’assemblage : Construire une application métier à forte valeur ajoutée en liant entre eux un ensemble de composants.

Ainsi, SCA insiste sur une séparation forte entre l’implémentation des services et leur assemblage.Le modèle SCA se veut agnostique vis-à-vis :

• Des technologies d’implémentation des composants de service. Il inclut entre autre les technologies d’implémentation suivantes : Java, C++, BPEL, XQuery ou SQL.
• Des technologies d’exposition et d’invocation des composants de services (même si WSDL et les interfaces java sont mis en avant).

SCA permet de décrire des services et leur assemblage indépendamment de toutes considérations techniques d’implémentation.

Composants et services : Le modèle d’implémentation

L’élément de base de SCA est le composant qui constitue l’unité élémentaire de construction.

Un composant est une instance configurée d’implémentation où une implémentation est un code source fournissant des fonctionnalités.

Ces fonctionnalités sont exposées en tant que services en vue de leur utilisation par d’autre composant. Les services sont décrits au travers d’interfaces qui constituent le contrat de service. Ces contrats sont implémentés par le composant.

Les paramètres des services sont des structures de données pour lesquelles SCA recommande fortement l’utilisation de la spécification SDO (Service Data Objects) dont il est également l’instigateur.

L’implémentation peut s’appuyer sur des services fournis par d’autres composants dont elle dépend. Ces dépendances sont appelés références. Elles sont associées à des services qui peuvent être soit exposés par d’autre composants SCA soit exposé par des systèmes tiers (Web services, connecteurs JCA, …).

L’implémentation peut être paramétrable au travers de propriétés qui influencent le comportement d’une fonctionnalité. C’est le composant qui configure l’implémentation en fournissant des valeurs à ses propriétés et en liant les références aux services fournis par d’autres composants.
Le système de références associé à celui des interfaces permet de réaliser un couplage lâche (ou faible) entre les composants : Un composant consommateur de services ne connaît des composants fournisseurs de services sur lesquelles il s’appuie que les interfaces (contrat de service) des services qu’il consomme.

Composition et domaines : Le modèle d’assemblage

Le deuxième élément définit par SCA est le composé qui est un assemblage de composants, services, références, propriétés et des liens qui existent entre ces éléments.

Un composé n’est donc rien d’autre qu’un composant de plus haut niveau que ceux qui le compose (Il fournit des services, dépends de références et a des propriétés). Un composé peut donc à son tour être référencé par d’autres composants et utilisé au sein d’autres composés.

L’utilisation première du composé peut être « détournée » pour regrouper un ensemble d’éléments non nécessairement liés mais qui constitue un ensemble fonctionnel cohérent.

Au plus haut niveau, les composés sont déployés dans des domaines SCA qui regroupe l’ensemble des services pour un système fonctionnel.

Perspectives

SCA vise l’implémentation de services de haut niveau à forte valeur ajoutée (Services métier et organisationnels). De tels mécanismes seraient en effet coûteux pour des services purement techniques (que l’on se contentera de référencer pour les utiliser dans les composants).

Comme c’est souvent le cas, la spécification est déjà implémentée depuis longtemps par les éditeurs à son origine au sein de leurs produits estampillés SOA, notamment par IBM.

Du côté de l’open source, on notera le projet Tuscany[4] de la fondation Apache qui vise à fournir un environnement d’exécution SCA. Pour ce qui est des outils de conception / développement, on retiendra le projet Eclipse STP[5] (SOA Tools Platform) qui se base sur les modèles SCA.

[1] La spécification est disponible sur le site de l’OSOA [en].
[2] Le communiqué de presse chez Oracle : Open SOA Collaboration Chooses OASIS to Advance SCA and SDO Specifications [en].
[3] SCA avait été poussé par IBM et Oracle, rapidement rejoints par BEA et d’autres, mais sans Sun. Pour en savoir plus : SCA/SDO go to OASIS [en] sur InfoQ et JBI and SCA Are Complimentary! [en] sur le blog de Bruce Snyder.
[4] ApacheTuscany Project [en].
[5] SOA Tools Platform Project [en].